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

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

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 

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 

> 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.



In response to


pgsql-hackers by date

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

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