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