Re: pg_upgrade bug found!

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade bug found!
Date: 2011-04-10 04:52:01
Message-ID: 201104100452.p3A4q1v11216@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message tomas 2011-04-10 05:37:54 Re: How would sorting work with millions of rows in a huge DB with PG?
Previous Message Stephen Frost 2011-04-10 02:23:00 Re: using a lot of maintenance_work_mem