-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lock_timeout + lock_timeout_retries + concurrent postgres indexes #233
Comments
I am experiencing the same thing and have maybe a different confusion about it. I experience this from time to time. If I'm unable to get the lock, why would an invalid index be left behind? wouldn't the attempt to make the index need to wait for the lock?
i think the behavior might make sense if it were a query timeout. is it possible there's a bug that erroneously reports query timeouts as lock timeouts, maybe only without ddl and/or with concurrent indexing, something like that? |
FWIW I've patched |
I'm not even sure if this is a bug, but I ran into the following situation this morning:
lock_timeout = 10.seconds
andlock_timeout_retries = 3
.disable_ddl_transaction!
), and that index can be deleted or reindexed concurrently.if_not_exists: true
.I wonder if this is something that could be solved in scope of this gem. Maybe a safety warning that concurrent index creation + lock_timeout can lead to this scenario?
For reference, used versions:
The text was updated successfully, but these errors were encountered: