-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Avoid cancel and terminate backends #76
Comments
Is this already implemented now in 1.3.4? |
See also closed issue, 90 |
@MichaelDBA : Thanks for pointing me at Your issue #90. As of changelog for 1.3.4 there is not implemented the requested feature. For simplicity of issue tracking we can close this issue (as duplicity of #90) and continue in #90 as you requested the same funcionality (with better description :-)). Regards, |
Issue 90 is also closed out, so is this feature implemented in pg_repack now? If so, what version will it be released in? |
Hello,
as I can't afford to happen pg_cancel_backend() or pg_terminate_backend() on a production DB (which could come up if pg_repack is waiting for --wait-timeout for its lock on repacked table), is it completly safe (in not running cancel/terminate way) to run pg_repack as follows?
timeout -s SIGINT 180s pg_repack --host=myhost --username=pgrepack_user --dbname=mydb --table=my table --wait-timeout=360
The point is:
...therefore the wait-timeout should never happen and pg_repack should never send pg_cancel_backend() and pg_terminate_backend() - is it right?
Update: could it be possible to add an option for pg_repack to run it in "do not harm anyone" mode - avoiding running pg_cancel/terminate_backend() and after a wait_timeout it just rollback its changes and exit?
Thanks for help,
Jiri
The text was updated successfully, but these errors were encountered: