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