On May 2, 2007, at 5:39 PM, Alvaro Herrera wrote:
The recently discovered autovacuum bug made me notice something
that is
possibly critical. The current autovacuum code makes an effort not to
leave workers in a "starting" state for too long, lest there be
failure
to timely tend all databases needing vacuum.
This is how the launching of workers works:
1) the launcher puts a pointer to a WorkerInfo entry in shared memory,
called "the starting worker" pointer
2) the launcher sends a signal to the postmaster
3) the postmaster forks a worker
4) the new worker checks the starting worker pointer
5) the new worker resets the starting worker pointer
6) the new worker connects to the given database and vacuums it
The problem is this: I originally added some code in the autovacuum
launcher to check that a worker does not take "too long" to start.
This
is autovacuum_naptime seconds. If this happens, the launcher
resets the
starting worker pointer, which means that the newly starting worker
will
not see anything that needs to be done and exit quickly.
The problem with this is that on a high load machine, for example
lionfish during buildfarm runs, this would cause autovacuum starvation
for the period in which the high load is sustained. This could prove
dangerous.
The problem is that things like fork() failure cannot be communicated
back to the launcher. So when the postmaster tries to start a process
and it fails for some reason (failure to fork, or out of memory) we
need
a way to re-initiate the worker that failed.
The current code resets the starting worker pointer, and leave the
slot
free for another worker, maybe in another database, to start.
I recently added code to resend the postmaster signal when the
launcher
sees the starting worker pointer not invalid -- step 2 above. I think
this is fine, but
1) we should remove the logic to remove the starting worker
pointer. It
is not needed, because database-local failures will be handled by
subsequent checks
2) we should leave the logic to resend the postmaster, but we should
make an effort to avoid sending it too frequently
Opinions?
If I haven't stated the problem clearly please let me know and I'll
try
to rephrase.
Isn't there some way to get the postmaster to signal the launcher?
Perhaps stick an error code in shared memory and send it a signal?
--
Jim Nasby [EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
