Re: pg_upgrade bug found! - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade bug found!
Date
Msg-id 201104091059.p39AxcK26471@momjian.us
Whole thread Raw
In response to Re: pg_upgrade bug found!  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: pg_upgrade bug found!  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Alvaro Herrera wrote:
> 
> Why is it important to have the original pg_clog files around?  Since
> the transactions in question are below the freeze horizon, surely the
> tuples that involve those transaction have all been visited by vacuum
> and thus removed if they were leftover from aborted transactions or
> deleted, no?  So you could just fill those files with the 0x55 pattern
> (signalling "all transactions are committed") and the net result should
> be the same.  No?
> 
> Forgive me if I'm missing something.  I haven't been following this
> thread and I'm more than a little tired (but wanted to shoot this today
> because I'm gonna be able to, until Monday).

Well, in most cases vacuum (or SELECT?) is going to set those xids as
committed on the tuple, but if there have been few deletes in the toast
table, it is possible vacuum did not run.  I think the fact we only have
three report query error cases is because in most cases vacuum is
already taking care of this as part of space reuse.

relfrozenxid is not going to cause freeze to run and therefore those
xids, even though marked as committed, still are on the tuple, so we
need this script to be run.

In fact, if the tuple is marked as committed, do we even bother to mark
the xids as fixed via vacuum freeze?  Seems we don't have to.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade bug found!
Next
From: Bruce Momjian
Date:
Subject: Re: pgindent