"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])