Re: bg worker: patch 1 of 6 - permanent process

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bg worker: patch 1 of 6 - permanent process
Date: 2010-08-26 10:07:00
Message-ID: 4C763CC4.6040201@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-08-26 10:15:41 Re: gSoC add MERGE command new patch -- merge_v104
Previous Message Andrew Dunstan 2010-08-26 09:56:23 Re: WIP: extensible enums