Re: temporarily stop autovacuum

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: temporarily stop autovacuum
Date: 2009-02-11 15:47:04
Message-ID: 603c8f070902110747j750f105ai473fd8074bf515d3@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 10, 2009 at 8:53 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> I'm not sure that this calls for a change in autovacuum itself; it seems
> to be that whatwe really need is the ability to change postgresql.conf
> settings from the SQL interface. This has been discussed at length
> elsewhere, and I think we need to bite the bullet eventually.

I'd like to take a crack at identifying the bullet that needs to be
bitten here: comments.

People like to use comments to document old settings that they may
once have had, and why they changed them, and we also ship comments
that document the meaning of many of our settings. IIRC, much of the
last round of this discussion centered on where new settings would be
inserted into the file (which might involve trying to identify the
commented-out version of that setting), whether to comment out the old
line for a particular setting and insert a new line (or just replace
the old line), what to do about comments on the same line as the GUC,
etc.

Any solution that we attempt to engineer this problem is unlikely to
be able to pass the Turing test, and so it's likely to get some cases
"wrong", as judged by the human intelligence of the person who wrote
the comment that got masticated.

If we resign ourselves to the fact that this will not work very well
unless our postgresql.conf file is intended to be read and written
primarily by machines, and only secondarily by humans when necessary
to recover from a bad situation, we can make some progress.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2009-02-11 16:19:38 Re: Optimization rules for semi and anti joins
Previous Message Robert Haas 2009-02-11 15:20:37 Re: advance local xmin more aggressively