Hi,
thanks for your feedback on this, it sort of got lost below the
discussion about the dynamic shared memory stuff, IMO.
On 08/26/2010 04:39 AM, Robert Haas wrote:
It's not clear to me whether it's better to have a single coordinator
process that handles both autovacuum and other things, or whether it's
better to have two separate processes.
It has been proposed by Alvaro and/or Tom (IIRC) to reduce code
duplication. Compared to the former approach, it certainly seems cleaner
that way and it has helped reduce duplicate code a lot.
I'm envisioning such a coordinator process to handle coordination of
other background processes as well, for example for distributed and/or
parallel querying.
Having just only one process reduces the amount of interaction required
between coordinators (i.e. autovacuum shouldn't ever start on databases
for which replication didn't start, yet, as the autovacuum worker would
be unable to connect to the database at that stage). It also reduces the
amount of extra processes required, and thus I think also general
complexity.
What'd be the benefits of having separate coordinator processes? They'd
be doing pretty much the same: coordinate background processes. (And
yes, I clearly consider autovacuum to be just one kind of background
process).
I agree with this criticism, but the other thing that strikes me as a
nonstarter is having the postmaster participate in the imessages
framework.
This is simply not the case (anymore). (And one of the reasons a
separate coordinator process is required, instead of letting the
postmaster do this kind of coordination).
Our general rule is that the postmaster must avoid
touching shared memory; else a backend that scribbles on shared memory
might take out the postmaster, leading to a failure of the
crash-and-restart logic.
That rule is well understood and followed by the bg worker
infrastructure patches. If you find code for which that isn't true,
please point at it. The crash-and-restart logic should work just as it
did with the autovacuum launcher.
Regards
Markus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
