"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Actually, I intentionally had pg_autovacuum continue to use libpq based 
> Tom's advise.  Please see this thread:
> http://archives.postgresql.org/pgsql-hackers/2004-03/msg00931.php
> And more specifically, these follow ups:
> http://archives.postgresql.org/pgsql-hackers/2004-03/msg00989.php
> http://archives.postgresql.org/pgsql-hackers/2004-03/msg00992.php

Something seems to have truncated msg00987 in the archives, but I
looked it up in my own mail folder ...

                        regards, tom lane

------- Forwarded Message

Date:    Mon, 22 Mar 2004 16:38:43 -0500
From:    Tom Lane <[EMAIL PROTECTED]>
To:      Gavin Sherry <[EMAIL PROTECTED]>
cc:      "Matthew T. O'Connor" <[EMAIL PROTECTED]>,
         Bruce Momjian <[EMAIL PROTECTED]>,
         Christopher Kings-Lynne <[EMAIL PROTECTED]>,
         Peter Eisentraut <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: [HACKERS] pg_autovacuum next steps 

Gavin Sherry <[EMAIL PROTECTED]> writes:
> So, do we want a static time, a GUC controlled time or some time which is
> modified by pg_autovacuum's/stat's collector's knowledge of the amount of
> work which goes on in any given database?

>From the point of view of the postmaster a GUC-controlled delay would
seem like the best thing.  We could discuss having the autovacuum code
try to feed back adjustments in the delay, but remember that one of the
golden virtues for the postmaster proper is simplicity; that translates
directly to robustness.  We don't want the postmaster engaging in
anything complicated that could potentially lock it up or crash it due
to a bug.

Possibly this point could be finessed by a two-level structure, that is,
postmaster launches autovacuum daemon (which is not itself a backend)
and that in turn launches backends to do the real per-database work.
The postmaster's only subsequent involvement is restarting the autovac
daemon if it dies.  The autovac daemon can be as complex as you want.

This nice-sounding arrangement is probably not directly workable because
of the fact that the postmaster has no good way to know about or control
backends if they aren't its direct children.  Perhaps the autovac daemon
*should* use libpq, that is, not fork backends but connect via the
postmaster each time it wants to run a backend.  Then the backends are
ordinary children of the postmaster and everything acts normally.
(This could amount to using the existing autovac code, and simply adding
a frammish to the postmaster to autospawn the autovac daemon as a
non-backend child process.)

                        regards, tom lane

------- End of Forwarded Message

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to