Re: Problem with pg_upgrade?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Problem with pg_upgrade?
Date: 2011-03-30 20:46:00
Message-ID: AANLkTinkMuSyeR-psML9ofAoXphnd0Dbwu8JdDmvgpsn@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 30, 2011 at 10:57 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> I think we have three options:
>
>        o  find if the use of autovacuum_freeze_max_age is safe, or make
>           it safe
>        o  document that autovacuum_naptime always happens before
>           autovacuum does anything and set it high
>        o  modify autovacuum to be an enum, with values on/off/disabled
>
> I think the last one makes more sense, and is safer if we need to
> backpatch this.  Creating a new variable for this would be confusing
> because it could conflict with the 'autovacuum' setting.

I have to admit the prospect of abuse is slightly frightening to me
here. I guess we can't be held responsible for users who do dumb
things, but it might not be too clear to someone what the difference
is between autovacuum=off and autovacuum=disabled. I don't really
understand why this is an issue in the first place, though. Surely we
must be setting the XID counter on the new cluster to match the one on
the old cluster, and migrating the relfrozenxid and datfrozenxid
settings, so why does it matter if someone runs vacuum freeze?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-03-30 20:48:26 Re: deadlock_timeout at < PGC_SIGHUP?
Previous Message Jan Wieck 2011-03-30 20:45:10 Re: Triggers on system catalog