PGPROCs of autovac workers (was Re: [PATCHES] autovacuum multiworkers, patch 5) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject PGPROCs of autovac workers (was Re: [PATCHES] autovacuum multiworkers, patch 5)
Date
Msg-id 20070409165812.GD10785@alvh.no-ip.org
Whole thread Raw
List pgsql-hackers
Alvaro Herrera wrote:

> Thanks!  I had already incorporated the foreach_worker changes into my
> code, and later realized that there's an important bug regarding the
> PGPROC of the workers, so I've reworked the patch, which meant that the
> foreach_worker() macro went away completely.

FWIW, the problem was that it is difficult to keep the "max_connections"
control and still allow extra connections for autovacuum so that it
doesn't hinder regular operation.  The first thing I tried was enlarging
the PGPROC array, but the problem with that is that the max_connection
tests get unwieldy (it would have to cycle through all used PGPROCs and
count the autovacuum ones).

So I'm now leaning towards having autovacuum keep their PGPROCs
separately, similarly to what the 2-phase code does, the main difference
being that 2PC doesn't have semaphores, while these ones will because
they need to acquire locks.

This needs a bit of rejigger in InitProcess() so that it acquires a
PGPROC from ProcGlobal if a regular backend, or from autovac's array
otherwise.  This has not been very invasive.

If there's an objection to this, and/or better ideas, please speak
quickly!

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: What X86/X64 OS's do we need coverage for?
Next
From: Tom Lane
Date:
Subject: Re: What X86/X64 OS's do we need coverage for?