Re: WIP: getting rid of the pg_database flat file - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: getting rid of the pg_database flat file
Date
Msg-id 2681.1250042402@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: getting rid of the pg_database flat file  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: WIP: getting rid of the pg_database flat file  (Alvaro Herrera <alvherre@commandprompt.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: dependencies for generated header files
Next
From: Greg Stark
Date:
Subject: Re: "Hot standby"?