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 Oosterhout||Date: 2007-01-27 05:31:01|
|Subject: Re: PostgreSQL Data Loss|
|Previous:||From: Tom Lane||Date: 2007-01-27 05:04:40|
|Subject: Re: How does EXEC_BACKEND process signals? |
pgsql-patches by date
|Next:||From: Pavan Deolasee||Date: 2007-01-27 05:50:17|
|Subject: Ctid chain following enhancement|
|Previous:||From: Jeremy Drake||Date: 2007-01-27 00:56:07|
|Subject: Re: [HACKERS] less privileged pl install|