-
Notifications
You must be signed in to change notification settings - Fork 171
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
WARNING: canceling conflicted backends #90
Comments
The "canceling conflicted backends" message is |
You said, "...and has resorted to killing other backends which appear to be interfering." pg_repack is trying to execute pg_terminate_backend() or pg_cancel_backend() on other pids? If so, can you specify a parameter that will stop pg_repack from doing this? If not, which is it, pg_cancel.. or pg_terminate? |
The (simplified) logic is:
So you could set |
Wow, I want to avoid pg_repack acting like a DBA by canceling statements or killing connections. If I set the wait_timeout to some arbitrarily large value that would never get invoked, can I kill the pg_repack PIDs at that point without damaging the table(s) involved? Otherwise, I gotta be monitoring the process to make sure we do not hit these waiting conditions. I think this is a strategic feature to have the option of pg_repack ending gracefully if it exceeds the wait timeout and not be allowed to cancel or terminate other PIDs. My manager would not let me use pg_repack if he knew that it can go out and kill other PG Pids. There goes the cron jobs to clean up the db. |
I use pg_repack extensively too and I like Mike's idea - end gracefully On Tue, Aug 9, 2016 at 6:13 PM, Michael Vitale notifications@github.com
Mark Steben www.fb.com/DominionDealerSolutions |
Yeah, this seems like a reasonable request. Shouldn't be too hard to optionally bail out and call
|
@schmiddy : As this issue was closed after releaes of 1.3.4, may I ask You when there will be new version of pg_repack with functionality requested? My production use of pg_repack is heavily dependent on it the same way as @MichaelDBA is. |
When will this functionality be available? I am also prohibited from using this in a production environment due to the invasive nature of this function killing other PIDs. |
Since this issue is now closed, is this feature implemented now? If so, when will it be released? |
You will have to specify --no-kill-backend parameter from: https://pgxn.org/dist/pg_repack/1.4.0/doc/pg_repack.html |
I see that this can occur if timeout is exceeded, but is there anything in bad shape when it aborts this way? Or does pg_repack clean up gracefully, ie, table(s) are back in their original condition?
I was using 1.3.3 version when this occurred on pg 9.4.8, debian wheezy
The text was updated successfully, but these errors were encountered: