Re: Autovacuum vs statement_timeout

Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> 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.

Hm, that's an interesting thought, but there are no "terminating
connection" messages in Shuttleworth's logs either. So we still lack
the right idea there. (BTW it would be SIGTERM not SIGINT.)

> 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.

You're thinking too small --- what this thought actually suggests is
that PG_CATCH can't be used to clean up shared memory at all, and I
don't think we want to accept that. (I see several other places already
where we assume we can do that. We could convert each one into an
on_proc_exit cleanup operation, maybe, but that seems messy and not very
scalable.) I'm thinking we may want to redesign elog(FATAL) processing
so that we escape out to the outer level before calling proc_exit,
thereby allowing CATCH blocks to run first.

Note for the archives: I've argued for some time that SIGTERM'ing
individual backends is an insufficiently tested code path to be exposed
as standard functionality. Looks like that's still true. This is not
a bug for database shutdown because we don't really care if we leave
perfectly clean shared memory behind --- it's only a bug if you try to
SIGTERM an individual vacuum process while leaving the system up.

regards, tom lane