Re: WIP: getting rid of the pg_database flat file

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: WIP: getting rid of the pg_database flat file
Date: 2009-08-12 13:35:48
Message-ID: 20090812133548.GC5721@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-08-12 13:38:30 Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)
Previous Message Tom Lane 2009-08-12 13:35:30 Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)