Re: Moving pg_autovacuum from contrib to src/bin

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Moving pg_autovacuum from contrib to src/bin
Date: 2004-05-29 15:04:58
Message-ID: 20107.1085843098@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Matthew T. O'Connor wrote:
>> I did understand Tom, but based on the hacker discussion I think the
>> "postmaster integration" will consist of the postmaster launching and
>> killing the pg_autovacuum standalone executable as required. In that
>> sense, I don't think it matters if pg_autovacuum is located in
>> src/bin or src/backend/postmaster.

> It is supposed to be linked into the postmaster and forked from there.

In the current state of pg_autovacuum it wouldn't matter a lot, but
I am assuming that we will soon migrate it to depend on being part of
the postmaster environment. For instance, it ought to be configured
from GUC, which will mean it has to receive SIGHUP from the postmaster.
In an only slightly longer timeframe, it will probably want access to
shared memory so it can look at stats maintained in the FSM. These
attributes would make it quite inappropriate for autovacuum to live in
src/bin.

BTW, Matthew, I am currently working on promoting the bgwriter into a
more full-fledged postmaster child. If you can wait a day or so you
should have a decent model to work from. I'll try to commit as soon
as a working skeleton is in place.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-05-29 15:20:56 Re: dynamic_library_path on Win32
Previous Message Andrew Dunstan 2004-05-29 13:24:53 Re: dynamic_library_path on Win32