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

From Alvaro Herrera
Subject Re: WIP: getting rid of the pg_database flat file
Date
Msg-id 20090812133548.GC5721@alvh.no-ip.org
Whole thread Raw
In response to Re: WIP: getting rid of the pg_database flat file  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP: getting rid of the pg_database flat file  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:

> 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.

Hmm, probably we could do this.  The one open question is how would it
know what to do the first time around when there's no information set up
yet, so it cannot start a worker.  I guess we could hardcode to start a
worker in database with Id 1, but that doesn't seem like an improvement.

> Is there a real downside to promoting the launcher to be a
> pseudo-backend?

Aside from the fact that we don't have any pseudo-backend yet, I don't
see any ...

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Next
From: Alvaro Herrera
Date:
Subject: Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)