On Aug 27, 2004, at 3:37 PM, Matthew T. O'Connor wrote:
> 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.
Yeah, so what I'm planning to write will probably just be a small
Perl/shell script containing roughly the logic below. To me, it seems a
bit shy of a general hole plugger, but maybe people will find it
useful. I guess I'll post my final draft and let the community have at
improving it.
>> 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?
Hmm. If the above situation is true, does it matter whether
pg_autovacuum knows whether the postmaster restarted?
>> 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.
Based on what you say above, though, is it even necessary to kill it?
Why not just observe that it's running and fail to start a new one?
Unless there's a need to restart pg_autovacuum if postmaster restarts.
-tfo