Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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


pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group