Open bastelfreak opened 2 years ago
Canceled queries are the expected and default behavior of pg_repack
if it spends more than 60 seconds waiting for an exclusive lock to be granted. Exclusive lock requests are very impactful and having pg_rpack
cancel and proceed or time out is critical as all other database activity on the requested table is corked behind that request until it concludes.
Shifting the behavior to "just time out" would be a bad trade-off for environments where long-running queries are frequent enough that pg_repack
commonly intersects with one. In these cases, table maintenance would never proceed and the eventual performance degradation would be a worse outcome than an occasional canceled query.
I'm not yet a pg_repack expert. Would it help to run pg_repack with more jobs or split the others systemd timer up into one per table?
Describe the Bug
pg_repack aborts and kill other pids?
Expected Behavior
pg_repack should terminate without killing other queries
Steps to Reproduce
I'm not sure how to reproduce. maybe with a primary and too slow disks.
Environment
Additional Context
pe_databases-catalogs
pe_databases-facts
pe_databases-other
log from one of the puppetdbs
more infos