Re: pg_autovacuum next steps

Tom Lane wrote:

>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?