Re: pg_upgrade bug found!

Aidan Van Dyk wrote:
> On Sat, Apr 9, 2011 at 7:03 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Bruce Momjian wrote:
> >> 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).
> >
> > To answer your other question, it is true we _probably_ could assume all
> > the rows were committed, except that again, vacuum might not have run
> > and the pages might not be full so single-page cleanup wasn't done
> > either.
>
> OK, continuing the thought of just making all the old clog files as
> "all committed"...
>
> Since it only affects "toast" tables, the only time the system (with
> normal queries) would check for a particular toast tuple, the tuple
> referring to it would have been committed, right? So forcing "all
> transactions committed" for the older clog segments might mean a scan
> on a *toast* heap might return tuples as committed when they might
> have been aborted, but the real table heap would never refer to those,
> right?

Uh, good point. I think you are right that you only get to a toast row
from a non-aborted heap row. I think the problem might be in following
the toast chain but even then I am unclear how that works. Anyone?

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

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