Open iggyzap opened 6 years ago
Hi,
I've noticed interesting tool behavior - when postgres kicks off anti-wraparound vacuum for a table, pg_repack fails to notice that when re-generating table's indexes: 78434 | postgres | 115732 | postgres | relation | ShareUpdateExclusiveLock | CREATE UNIQUE INDEX CONCURRENTLY index_22456 ON <table> U | autovacuum: VACUUM ANALYZE <table> (to prevent wraparound
78434 | postgres | 115732 | postgres | relation | ShareUpdateExclusiveLock | CREATE UNIQUE INDEX CONCURRENTLY index_22456 ON <table> U | autovacuum: VACUUM ANALYZE <table> (to prevent wraparound
That issue reduces pg_repack usability, since it can be stuck virtually forever if autovacuum is run for days.
I can extract what locks are held if required.
PS. I've tried to make output of lock dump prettier, but to no avail.
With regards, Ignat Zapolsky.
Similar issues have been brought up in https://github.com/reorg/pg_repack/issues/95 and #26.
Hi,
I've noticed interesting tool behavior - when postgres kicks off anti-wraparound vacuum for a table, pg_repack fails to notice that when re-generating table's indexes:
78434 | postgres | 115732 | postgres | relation | ShareUpdateExclusiveLock | CREATE UNIQUE INDEX CONCURRENTLY index_22456 ON <table> U | autovacuum: VACUUM ANALYZE <table> (to prevent wraparound
That issue reduces pg_repack usability, since it can be stuck virtually forever if autovacuum is run for days.
I can extract what locks are held if required.
PS. I've tried to make output of lock dump prettier, but to no avail.
With regards, Ignat Zapolsky.