Re: pg_autovacuum next steps - Mailing list pgsql-hackers

From Matthew T. O'Connor
Subject Re: pg_autovacuum next steps
Date
Msg-id 1079940937.13076.76.camel@zeudora.zeut.net
Whole thread Raw
In response to Re: pg_autovacuum next steps  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: pg_autovacuum next steps
Re: pg_autovacuum next steps
List pgsql-hackers
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 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
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.

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. 

Thanks again...

Matthew




pgsql-hackers by date:

Previous
From: Karel Zak
Date:
Subject: Re: COPY formatting
Next
From: Gavin Sherry
Date:
Subject: Re: pg_autovacuum next steps