Closed kustodian closed 9 years ago
Just to update this issue with more clarifications (issue is written by my collegue). pg_dump took AccessShareLock on "table_a", and pg_compact later tried to lock it with AccessExclusive lock to remove contstraint on primary key. It got canceled three times because of timeout, and after that it blocked for 10 minutes waiting for pg_dump to release its lock and it got stucked. It didn't retry for 10 times and gave up, it waited for 10 minutes, and all other queries that wanted to update this table got stucked waiting for pgcompact to release request for AccessExclusiveLock.
@kustodian @XooR thank you for your feedback. It looks like a serious issue, all 3 of them actually, and I'm definitely going to review them in the nearest future. Unfortunately, I'm pretty restricted in terms of time now so I can not promise results earlier than the next week, but I'm going to do my best here. Thanks again.
Thank you for reporting that. It is definitely a bug.
The code has a block https://github.com/grayhemp/pgtoolkit/blob/master/lib/PgToolkit/Compactor/Table.pm#L707-L748 that implements a retry loop with 500ms statement timeout for heavy locking statements to soften the locks impact. And this blocking DROP INDEX
should actually be inside of it, but it is not https://github.com/grayhemp/pgtoolkit/blob/master/lib/PgToolkit/Compactor/Table.pm#L775.
So I'm putting this issue into my TODO list for the next release.
As I can see there are no straight solution for this problem, but it can be worked around as I made in the ac34520 commit.
A few days ago I had an issue where
pgcompact
was running a little longer than usual so it continued to run whenpg_dump
started to dump the database. Because of this my application locked for more than 10 minutes. I'm not sure ifpgcompact
should be safe againstpg_dump
, but it would be great if it is. Here is part of the postgres log which caused the lock:This is on Postgres 9.1 and I'm sorry for not having more information. Also I haven't checked into detail, but this issue could be related to issue #5.