Re: pg_autovacuum next steps

Поиск
Список
Период
Сортировка
От Matthew T. O'Connor
Тема Re: pg_autovacuum next steps
Дата
Msg-id 1079940937.13076.76.camel@zeudora.zeut.net
обсуждение исходный текст
Ответ на Re: pg_autovacuum next steps  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: pg_autovacuum next steps  (Gavin Sherry <swm@linuxworld.com.au>)
Re: pg_autovacuum next steps  (Karel Zak <zakkr@zf.jcu.cz>)
Список 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 по дате отправления:

Предыдущее
От: Karel Zak
Дата:
Сообщение: Re: COPY formatting
Следующее
От: Gavin Sherry
Дата:
Сообщение: Re: pg_autovacuum next steps