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?