Prev: [HACKERS] bg worker: patch 3 of 6 - sockets
Next: [HACKERS] bg worker: patch 6 of 6 - ooo messages
From: Markus Wanner on 13 Jul 2010 10:31 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 http://archives.postgresql.org/message-id/ab0cd52a64e788f4ecb4515d1e6e4691(a)localhost
|
Pages: 1 Prev: [HACKERS] bg worker: patch 3 of 6 - sockets Next: [HACKERS] bg worker: patch 6 of 6 - ooo messages |