-
Notifications
You must be signed in to change notification settings - Fork 68
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
pg_advisory_lock vs. pg_try_advisory_lock #80
Comments
pg_try_advisory_lock is non blocking. You don't want to have processes blocked because they are waiting for the lock . You can close this Issue if this answer your question. |
What do you mean non blocking? Both try to obtains an exclusive session-level advisory lock.
I just see that with or do you mean that with To be short, what the benefit of |
I see your point, we could have a option to select the behaviour. Do you want to open a PR for it ? |
I can try when will have a bit more free time. Currently just busy on the project where I wanted to apply |
This is a critical bug with the PostgreSQL implementation, as far as I understand. Currently, The "What Happens" section in the README states:
But in reality, if another process already holds the lock, it will just skip the block silently without executing it. |
...false alarm. My bad. I didn't realize that But I agree with @AleksandrLeontev and his notion that the current approach of using |
Why do you use
pg_try_advisory_lock
and not just simplepg_advisory_lock
which will avoid polling in SQL?You can plan with this example:
The text was updated successfully, but these errors were encountered: