Re: pg_upgrade bug found!

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: 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-07 21:52:55
Message-ID: 201104072152.p37Lqta01401@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis wrote:
> On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote:
> > > Any idea how to correct existing systems? Would VACUUM FREEZE of just
> > > the toast tables work?
> >
> > VACUUM FREEZE will never set the relfrozenxid backward. If it was never
> > preserved to begin with, I assume that the existing value could be
> > arbitrarily before or after, so it might not be updated.
>
> Now that I understand the problem a little better, I think VACUUM FREEZE
> might work, after all.

Good. I don't want to be inventing something complex if I can avoid it.
Simple is good, espeically if admins panic. I would rather simple and
longer than short but complex :-)

> Originally, I thought that the toast table's relfrozenxid could be some
> arbitrarily wrong value. But actually, the CREATE TABLE is issued after
> the xid of the new cluster has already been advanced to the xid of the
> old cluster, so it should be a "somewhat reasonable" value.

Yes, it will be reasonable.

> That means that VACUUM FREEZE of the toast table, if there are no
> concurrent transactions, will freeze all of the tuples; and the
> newFrozenXid should always be seen as newer than the existing (and
> wrong) relfrozenxid. Then, it will set relfrozenxid to newFrozenXid and
> everything should be fine. Right?

Right.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-04-07 22:11:12 Re: pg_upgrade automatic testing
Previous Message Jeff Davis 2011-04-07 21:48:58 Re: pg_upgrade bug found!