Tom Lane wrote:
> I seem to remember that we'd agreed that autovacuum should ignore any
> globally set statement_timeout, on the grounds that a poorly chosen
> setting could indefinitely prevent large tables from being vacuumed.
> But I do not see anything in autovacuum.c that resets the variable.
> Am I just being blind? (Quite possible, as I'm tired and under the
> weather.)
>
> The thing that brought this to mind was the idea that Mark
> Shuttleworth's open problem might be triggered in part by a statement
> timeout interrupting autovacuum at an inopportune point --- some logs
> he sent me offlist show that he is using statement_timeout ...
statement_timeout interrupts seem to go through the PG_CATCH-block and
clean up the entry from the vacuum cycle array as they should. But a
SIGINT leading to a "terminating connection due to administrator
command" error does not.
After the recent change in CVS HEAD, CREATE DATABASE tries to
kill(SIGINT) any autovacuum process in the template database. That seems
very dangerous now, it could easily leave stale entries in the cycle id
array. However, it doesn't explain the Mark Shuttleworth's problem
because the 8.2 behavior is to throw an "source database is being
accessed by other users" error instead of killing autovacuum. Maybe
there's something else killing autovacuum processes?
I think we need to add the xid of the vacuum transaction in the vacuum
cycle array, and clean up orphaned entries in _bt_start_vacuum. We're
going to have a hard time plugging every leak one-by-one otherwise.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
