Re: temporarily stop autovacuum - Mailing list pgsql-hackers

From Tom Lane
Subject Re: temporarily stop autovacuum
Date
Msg-id 11914.1234375846@sss.pgh.pa.us
Whole thread Raw
In response to Re: temporarily stop autovacuum  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: temporarily stop autovacuum  (Robert Haas <robertmhaas@gmail.com>)
Re: temporarily stop autovacuum  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Peter Eisentraut wrote:
>> More generally, it was pointed out to me that users apparently do  
>> updates of pg_autovacuum to change settings on a bunch of tables at  
>> once.  We might get some complaints if we remove that facility.

> Hmm, argh.  Maybe we do need the rule on a fake pg_autovacuum that
> Itagaki-san was proposing.

AFAIR we pointed out from day one that pg_autovacuum was a temporary
API that we were not promising to keep around.  Anybody who was coding
against it with the expectation that they'd not have to change that code
later was willfully ignoring the warning label.

> There's a problem however; for pg_autovacuum you used to need to insert
> some -1 values on columns on which you wanted to keep as defaults.  On
> the new code you need to skip the value altogether, and a -1 is rejected
> with an error.  Not sure how would we translate that.

Maybe use a real table with an ON INSERT trigger that could contain some
actual logic?  But it'd probably still have to be custom-tailored to
whatever application code was inserting things into pg_autovacuum,
so it's not clear there's much point to writing that instead of fixing
the application.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Next
From: Robert Haas
Date:
Subject: Re: temporarily stop autovacuum