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
Re: pg_autovacuum next steps |
Список | 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 по дате отправления: