On Sat, Apr 09, 2011 at 09:05:42AM -0400, Aidan Van Dyk wrote:
> On Sat, Apr 9, 2011 at 7:03 AM, Bruce Momjian <bruce@momjian.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?
Yes; it would be relatively harmless to retain some unreferenced TOAST chunks.
However, "all xacts committed" is not equivalent to "all tuples visible". If
the user rolled back a DELETE shortly before the pg_upgrade run, we need to
recognize that outcome to keep any deleted TOAST entries visible.