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

bg worker: patch 1 of 6 - permanent process

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: bg worker: patch 1 of 6 - permanent process
Date: 2010-07-13 14:31:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
This patch turns the existing autovacuum launcher into an always running 
process, partly called the coordinator. If autovacuum is disabled, the 
coordinator process still gets started and keeps around, but it doesn't 
dispatch vacuum jobs. The coordinator process now uses imessages to 
communicate with background (autovacuum) workers and to trigger a vacuum 
job. So please apply the imessages patches [1] before any of the bg 
worker ones.

It also adds two new controlling GUCs: min_spare_background_workers and 
max_spare_background_workers. The autovacuum_max_workers still serves as 
a limit for the total amount of background/autovacuum workers. (It is 
going to be renamed in step 4).

Interaction with the postmaster has changed a bit. If autovacuum is 
disabled, the coordinator isn't started with 
PMSIGNAL_START_AUTOVAC_LAUNCHER anymore, instead there is an 
IMSGT_FORCE_VACUUM that any backend might want to send to the 
coordinator to prevent data loss due to XID wrap around (see changes in 
access/transam/varsup.c). The SIGUSR2 from postmaster to the coordinator 
doesn't need to be multiplexed anymore, but is only sent to inform about 
fork failures.

A note on the dependency on imessages: for just autovacuum, this message 
passing infrastructure isn't absolutely necessary and could be removed. 
However, for Postgres-R it turned out to be really helpful and I think 
chances are good another user of this background worker infrastructure 
would also want to transfer data of varying size to and from these workers.

Just as in the current version of Postgres, the background worker 
terminates immediately after having performed a vacuum job.

Open issue: if the postmaster fails to fork a new background worker, the 
coordinator still waits a whole second after receiving the SIGUSR2 
notification signal from the postmaster. That might have been fine with 
just autovacuum, but for other jobs, namely changeset application in 
Postgres-R, that's not feasible.

[1] dynshmem and imessages patch

Attachment: step1-permanent_process.diff
Description: text/x-diff (51.1 KB)


pgsql-hackers by date

Next:From: Markus WannerDate: 2010-07-13 14:31:07
Subject: bg worker: patch 2 of 6 - job cache
Previous:From: Markus WannerDate: 2010-07-13 14:30:52
Subject: bg worker: overview

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