On Mon, 22 Mar 2004, Matthew T. O'Connor wrote:
> On Sun, 2004-03-21 at 23:00, Bruce Momjian wrote:
> > > > C) Most importantly, I'm not backend hacker. If someone wants to do the
> > > > initial work of getting it running as a backend process, I can take it
> > > > from there. A while ago, Bruce offered to help me with any backend
> > > > issues I might have, so perhaps with a little help I can take a run at
> > > > it.
> > >
> > > I'd be happy to help you out.
> >
> > Agreed.
>
> Ok, thanks for the offer to help, but I think I understated things above
> when I said I'll need a "little" help :-)
>
I haven't looked at the code but...
> I have a few big picture questions. Once pg_autovacuum is launched as a
> postmaster sub-process, what changes? That is, currently pg_autovacuum
> uses libpq to connect to a database and issue queries including a vacuum
> / analyze command when needed. After becoming a subprocess will
> (should) it still use libpq to connect to the databases, I don't think
It could use libpq but most definately shouldn't.
> so, is it even possible to do that? If not, how will it checkout the
> stats of all the different databases? I guess it should fork() a new
> backend, connect to it somehow, and use it to query the database, but
> I'm really not sure how this works.
It can interact with the stats collector (seperate backend) in the same
way that existing backends interact: through a domain socket.
> I'm looking through the backend startup code to see how the stats
> collector and the bgwriter work since they are probably two semi-close
> examples of what I'll have to do. I think checkpoints does something
> similar in that it issues a checkpoint command.
The vacuum backend will call vacuum() (or something very like it)
directly. I imagine that when it gets called and on which table will be
based upon the existing algorithm.
Thanks,
Gavin