From the point of view of the postmaster a GUC-controlled delay would
seem like the best thing. We could discuss having the autovacuum code
try to feed back adjustments in the delay, but remember that one of the
golden virtues for the postmaster proper is simplicity; that translates
directly to robustness. We don't want the postmaster engaging in
anything complicated that could potentially lock it up or crash it due
to a bug.
Agreed.
[snip...]
This nice-sounding arrangement is probably not directly workable because of the fact that the postmaster has no good way to know about or control backends if they aren't its direct children. Perhaps the autovac daemon *should* use libpq, that is, not fork backends but connect via the postmaster each time it wants to run a backend. Then the backends are ordinary children of the postmaster and everything acts normally. (This could amount to using the existing autovac code, and simply adding a frammish to the postmaster to autospawn the autovac daemon as a non-backend child process.)
Well this certainly sounds like something that would be easy to do, which appeals to me at least as a first cut. Question: Does this mean that I lose many of the advantages of being "in the backend"? That is, would pg_autovacuum still be able to use facilities such as GUC, error reporting, access to the FSM, direct pipe connection to the stats collector etc?
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
