Re: pg_autovacuum next steps

Tom Lane wrote:

>"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
>
>
>>I probably said that wrong, but how do backends get their stats data?
>>
>>
>
>They read it out of a flat file that the stats collector rewrites every
>so often.
>
>
>
Ok so that would be easy to do (if we decide we want to)

>Is that really worth the loss of independence? I'm not sure one way or
>the other myself. I suppose the autovac daemon could still be run by
>hand for testing purposes, but it would have to run as user postgres and
>on the same machine as the postmaster.
>
>
>
I'm not sure, it would allow autovacuum to check the stats more
regularly. I suppose it would be possible for pg_autovacuum to
recognize if it's been launched by the postmaster or not and look up
stats as appropriate, but as you say, I'm not sure it's worth it, and my
first cut will work exactly as the current pg_autovacuum does.

>>Also, you didn't mention if I will be able to use the backend logging
>>functions, I would guess that I can, but I'm not totally sure.
>>
>>
>
>Yes, if you are launched by the postmaster then you'd have access to its
>stderr etc, so you could just log via elog/ereport. Again though this
>puts you in a situation where the daemon *must* be launched by the
>postmaster or it won't work. How much arm's-length separation are you
>willing to give up?
>

Well I think I would be more willing to give up the separation for
logging purposes. I would think that an error message issued by a
postmaster sub-process should wind up in the same location as an error
issued by the postmaster proper. Also, people have requested lots of
logging options such as syslog etc and I think it would be nice to get
all this for free.

I would think that pg_autovacuum could determine if it's a postmaster
sub-process and log appropriately, does sound reasonable?