Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Here it is.
>
> I'd drop the InitProcess API change, which touches many more places than
> you really need, and just have InitProcess check IsAutoVacuumProcess(),
> which should be valid by the time control gets to it. This is more like
> the way that InitPostgres handles it, anyway.
Hmm, the problem is SubPostmasterMain, which is in the EXEC_BACKEND
path. It hasn't reached the autovacuum.c code yet, so it hasn't had the
chance to set the am_autovacuum static variable (in autovacuum.c). I
guess the answer here is to allow that variable to be set from the
outside.
> > Note that I used the same DatabaseHasActiveBackends() function to do the
> > kill.
>
> Agreed; maybe change the name to something that sounds less like a
> side-effect-free function?
I'm short on ideas on how to name it ...
DatabaseHasActiveBackendsAndKillAutovac() sounds a bit too much :-(
Maybe DatabaseCancelAutovacuumActivity()? (but then it's not obvious
that it counts other processes at all) And make it kill all autovac
processes inconditionally, which also fixes thing per your comment
below:
> > Another point to make is that it only kills autovacuum, and only if no
> > other process is found. So if there are two processes and autovacuum is
> > one of them, it will be allowed to continue.
>
> What if there are two autovac processes, which seems likely to be
> possible soon enough?
On the other hand, I was thinking that if we're going to have an autovacuum
launcher that's continuously running, we're going to have a lot of API
changes in this area anyway, so I wasn't in a hurry to consider the
posibility of two autovacuum processes. But I don't think it's very
important anyway.
PS -- first time I try to be strict about switching between
pgsql-hackers and pgsql-patches and already I find it a bit annoying ...
not to mention that this is probably going to look weird on the
archives.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.