| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| 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:48:58 |
| Message-ID: | 1302212938.19537.1.camel@jdavis-ux.asterdata.local |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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.
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?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2011-04-07 21:52:55 | Re: pg_upgrade bug found! |
| Previous Message | Bruce Momjian | 2011-04-07 21:47:00 | Re: pg_upgrade bug found! |