"Russell Smith" <[EMAIL PROTECTED]> writes: > Gregory Stark wrote: >> It seems there's something wrong with CheckOtherDBBackends() but I haven't >> exactly figured out what. There are no other sessions but drop database keeps >> saying "regression" is being accessed by other users. I do see Autovacuum >> touching tables in regression but CheckOtherDBBackends() is supposed to send >> it a sigkill if it finds it and it doesn't seem to be doing so. >> >> I've been hacking on unrelated stuff in this database and have caused >> multiple >> core dumps and autovacuum is finding orphaned temp tables. It's possible some >> state is corrupted in some way here but I don't see what. > > Autovacuum does this as well. I know on 8.1, I've been bitten by it a > number of times. I don't know for CVS or newer version than 8.1. But > it's an option worth considering as autovac doesn't show up in > pg_stat_activity.
In 8.3 autovacuum politely steps out of the way if it's holding up traffic (actually anyone who gets stuck behind vacuum just rudely shoots it in the back). So this *shouldn't* happen any more which is why I was raising it. However it was solved earlier by someone else. It was a a prepared transaction. Which was precisely what my comment about "some state is corrupted" meant. In this case the server had core dumped after preparing a transaction and that prepared transaction was blocking the DROP DATABASE. 8.4 will now print a better message specifically pointing out the prepared transactions for the next hapless DBA to be caught in this situation. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
