Autovacuum launcher - Mailing list pgsql-patches

From Alvaro Herrera
Subject Autovacuum launcher
Date
Msg-id 20070215014818.GA7758@alvh.no-ip.org
Whole thread Raw
Responses Re: Autovacuum launcher
List pgsql-patches
[resending, with the patch gzipped, as the previous one seems to be lost
-- I mistakenly sent it to -hackers instead of -patches]

Hi,

Here's the autovacuum launcher patch I'm considering for inclusion.

Possibly controversial stuff:

1. I changed InitPostgres to be able to get a database by OID.  This is
better than having to convert the OID to name in the launcher by reading
the pg_database flat file, and then back to OID in InitPostgres by
reading same.  I had to add a FindMyDatabaseByOid to this effect.
In autovacuum mode, InitPostgres() passes the database name back, so
that the autovacuum worker process doesn't have to compute it
separately.

2. I treat autovac workers as backends in Postmaster, and put them in
the regular list of backends.  This makes them respond to
SignalChildren() cleanly; and it means they don't need any special code
in case of shutdown, etc, because they are managed just like any other
backend.  I intended to add an is_autovacuum flag to the Backend struct,
but it turns out to be unnecessary.

Not so controversial, but maybe of note:

1. I removed all frammishes to slow down in case of failure (start_time,
stop_time, etc).

2. Autovacuum launcher is a dummy process, so it's treated specially in
postmaster.

3. Autovacuum now has a shared memory area.  Currently it's fairly small
and contains a single OID and a PID, but the idea is to extend it to
pass more info to the workers in future patches.


Other than that it seems fairly vanilla to me.


One thing I noticed is that when autovac is off, it may take up to 60
seconds to process a signal passed down via SendPostmasterSignal().
I assume this is due to our system calls being restartable, i.e. it's
restarted by the operating system after the signal is received (if this
is not the case please let me know).  This should not be much of a
problem, except if the postmaster is idle for a long time (for example
because all connections are served from a pool) and a lot of
transactions are consumed in the 60 sec period.  Not sure if I should
worry too much about this.


Comments are much appreciated.  I intend to apply this in a couple of
days unless there are objections.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Attachment

pgsql-patches by date:

Previous
From: Jeremy Drake
Date:
Subject: Re: patch adding new regexp functions
Next
From: Bruce Momjian
Date:
Subject: Re: patch adding new regexp functions