Tom Lane wrote:
> Also see Peter's nearby suggestion that we ought to wait instead of fail
> for *all* cases of somebody attached to the database. This would adapt
> readily enough to that.
>
> I was complaining elsewhere that I didn't want to use a sleep loop
> for fixing the fsync-synchronization issue, but CREATE/DROP DATABASE
> seems a much heavier-weight operation, so I don't feel that a sleep
> is inappropriate here.
Note that currently there's no way for a backend to know whether another
backend is autovacuum or not. I thought about adding a flag to PGPROC,
but eventually considered it ugly, so I started coding it as a shared
memory area instead, similar to what the bgwriter uses (storing the PID
there, etc). After that was almost done I noticed that it's not a very
good idea either because there's no way to clean the shmem if autovacuum
dies -- the only one who knows about it, postmaster, does not want to
have access to shmem, so it can't do it.
So I'm reverting to using the flag in PGPROC for now, with an eye
towards using shmem eventually if we decide that using an always-running
autovacuum launcher is a good idea.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.