New option PGBK_PAUSE_TIMEOUT #33
Conversation
A long query with AccessShareLock on master will be replicated, and will cause an internal loop when invoking pg_back on standby. To prevent multiple executions of pg_back on daily routine, this introduces a new option PGBK_PAUSE_TIMEOUT (-T) that waits an amount of time in seconds before dying. The pause/resume replay logic has been simplified.
Save to output of SHOW ALL to pg_settings_DATETIME.out
|
Hello, thanks for the patch. I would prefer to have a name like PGBK_STANDBY_PAUSE_TIMEOUT, which says this timeout relates to standby clusters. Other than that, it looks good. Regards |
|
Hi, Okay for renaming variable. The blocking behavior is relevant on primary cluster too, but internal loop isn't implemented for this case. For users who haven't replication, a long blocking session could cause multiple execution of pg_back, day after day. Regards |
|
Concerning the fact that a long run could conflict with the backup schedule, with pg_back processes stacking up, I guess a locking mecanism could be implemented using the |
A long query with AccessShareLock on master will be replicated, and will cause an internal loop when invoking pg_back on standby. To prevent multiple executions of pg_back on daily routine, this introduces a new option PGBK_PAUSE_TIMEOUT (-T) that waits an amount of time in seconds before dying. The pause/resume replay logic has been simplified.
pg_back
Outdated
| fi | ||
|
|
||
| echo "The standby database has exclusive locks (vacuum full, truncate or other locking command) running on primary" | ||
| echo "Resuming replication for ${PGBK_PAUSE}s" |
There was a problem hiding this comment.
I guess we could use warn() and info() here to print messages correctly. Could you please make to change?
Thank you
Add timeout behaviour when dumping standby in case of AccessExclusiveLocks #32