Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> 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)
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.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.
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?
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
