Re: pg_upgrade bug found!

From: Noah Misch <noah(at)leadboat(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, RhodiumToad on IRC <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade bug found!
Date: 2011-04-08 17:35:14
Message-ID: 20110408173514.GA32412@tornado.gateway.2wire.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 08, 2011 at 10:05:01AM -0700, Jeff Davis wrote:
> On Fri, 2011-04-08 at 07:08 -0400, Noah Misch wrote:
> > > Right, VACUUM FREEZE. I now see I don't need to set
> > > vacuum_freeze_table_age if I use the FREEZE keyword, e.g. gram.y has:
> > >
> > > if (n->options & VACOPT_FREEZE)
> > > n->freeze_min_age = n->freeze_table_age = 0;
> >
> > True; it just performs more work than strictly necessary. We don't actually
> > need earlier-than-usual freezing. We need only ensure that the relfrozenxid
> > will guide future VACUUMs to do that freezing early enough. However, I'm not
> > sure how to do that without directly updating relfrozenxid, so it's probably
> > just as well to cause some extra work and stick to the standard interface.
>
> If there are tuples in a toast table containing xids that are older than
> the toast table's relfrozenxid, then there are only two options:
>
> 1. Make relfrozenxid go backward to the right value. There is currently
> no mechanism to do this without compiling C code into the server,
> because (a) VACUUM FREEZE will never move the relfrozenxid backward; and
> (b) there is no way to find the oldest xid in a table with a normal
> snapshot.

Couldn't you set relfrozenxid and datfrozenxid to txid_current() - 1100000000
(the highest possible vacuum_freeze_min_age, plus some slop), then run "SET
vacuum_freeze_table_age = 0; VACUUM tbl" on all tables for which you did this?
There's no need to set relfrozenxid back to a particular "right" value. Not
suggesting we recommend this, but I can't think offhand why it wouldn't suffice.

> 2. Get rid of those xids older than relfrozenxid (i.e. VACUUM FREEZE).
>
> I don't know what you mean about VACUUM FREEZE doing extra work. I
> suppose you could set the vacuum_freeze_min_age to be exactly the right
> value such that it freezes everything before the existing (and wrong)
> relfrozenxid, but in practice I think it would be the same amount of
> work.

Suppose that your next xid at pg_upgrade time was 500M, and it's now 505M. If
you're using the default vacuum_freeze_min_age = 50M, "SET
vacuum_freeze_table_age = 0; VACUUM tbl" will only freeze tuples covering 5M
transaction ids. "VACUUM FREEZE tbl" (a.k.a "SET vacuum_freeze_table_age = 0;
SET vacuum_freeze_min_age = 0; VACUUM tbl") will freeze tuples covering 55M
transaction ids.

nm

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-04-08 17:35:33 Re: pg_upgrade bug found!
Previous Message Bruce Momjian 2011-04-08 17:26:13 Re: pg_upgrade bug found!