Re: Autovacuum launcher patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Autovacuum launcher patch
Date: 2007-01-27 05:14:31
Message-ID: 2340.1169874871@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> The launcher is a dummy process; it never connects to any database.
> ... Eventually this will need to
> be changed so that the launcher tells the worker exactly what table to
> work on.

I detect a certain lack of clarity of thinking here. Either the
launcher can read databases or it can't. Do you intend to solve the
problem of all the transaction/catcache infrastructure being designed
on the assumption of being in exactly one database?

I'd suggest sticking to something closer to the current two-phase design
where you make some preliminary decision which database to send a worker
to, and then the worker determines exactly what to do once it can look
around inside the DB. Possibly we need some back-signaling mechanism
whereby a worker can tell the launcher "hey boss, send help" if it sees
that there are enough tables that need work, but I'm unenthused about
having the launcher figure that out itself.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2007-01-27 05:31:01 Re: PostgreSQL Data Loss
Previous Message Tom Lane 2007-01-27 05:04:40 Re: How does EXEC_BACKEND process signals?

Browse pgsql-patches by date

  From Date Subject
Next Message Pavan Deolasee 2007-01-27 05:50:17 Ctid chain following enhancement
Previous Message Jeremy Drake 2007-01-27 00:56:07 Re: [HACKERS] less privileged pl install