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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org