Aidan Van Dyk wrote: > On Sat, Apr 9, 2011 at 7:03 AM, Bruce Momjian <br...@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?
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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
