Re: WIP: getting rid of the pg_database flat file

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WIP: getting rid of the pg_database flat file
Дата
Msg-id 2681.1250042402@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WIP: getting rid of the pg_database flat file  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: WIP: getting rid of the pg_database flat file  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> To actually get rid of the pg_database flat file, we'd need to take the
>> further step of teaching the AV launcher to read pg_database for itself,
>> or else refactor things so that the AV workers can do that for it.
>> (Alvaro, any comments about the best way to proceed there?)

> Hmm.  I don't see any easy way out of that at the moment ... the
> launcher would have to become a pseudo-backend, at least to the point
> where it is able to read pg_database.  I don't see how could workers
> help the launcher with that, unless we made them write a flatfile
> representation of pg_database, which would put us back where we started ...

> I'll have a deeper look around.

What was sort of in the back of my mind was to have every n'th AV worker
examine pg_database and report back to the launcher (probably through
shared memory) with an indication of the next few databases that should
be vacuumed and when.  Not sure how inefficient that might be though.
Is there a real downside to promoting the launcher to be a
pseudo-backend?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: dependencies for generated header files
Следующее
От: Greg Stark
Дата:
Сообщение: Re: "Hot standby"?