Thomas F.O'Connell wrote:
> I'm about to try to implement a simple pg_autovacuum script that can be
> used in conjunction with or integrated entirely with the contrib
> start-scripts for postgres. I just want to check that what I'm doing has
> the appropriate sanity checks.
Getting the startup and shutdown of pg_autovacuum coordinated with the
postmaster would address one of the big holes in contrib
(non-integrated) version of pg_autovacuum.
> The behavior I'm considering is:
>
> if pg_ctl status returns a good value then
> if pg_autovacuum is not running then
> start pg_autovacuum
> else
> error
> else
> error
>
> Based on what I (think I) know, this covers the cases where:
>
> 1. There is not a valid instance of postgres running.
> 2. There is already a valid instance of pg_autovacuum running (which can
> still run as a daemon even in the event that postgres is stopped, IIRC).
> 3. It is safe to start pg_autovacuum because neither of the above cases
> holds.
pg_autovacuum will exit when it can no longer connect to a postmaster.
The problem is that it might sleep for several minutes before it notices
that the postmaster has shutdown. So, you can restart the postmaster
and as long as pg_autovacuum never noticed that it went away, it will
keep chugging along as if nothing happened.
Is there anyway pg_autovacuum can know if the postmaster has restarted?
New PID? Or something better?
> Is this logic sufficiently sane?
Well if the script also sends a kill signal to pg_autovacuum that might
solve the pg_autovacuum still running problem.