From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: WIP: getting rid of the pg_database flat file |
Date: | 2009-08-12 02:00:02 |
Message-ID: | 2681.1250042402@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-08-12 02:00:43 | Re: "Hot standby"? |
Previous Message | Tom Lane | 2009-08-12 01:56:37 | Re: dependencies for generated header files |