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. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
