On Fri, Oct 18, 2013 at 2:26 PM, Andres Freund <and...@2ndquadrant.com> wrote: > So. As it turns out that solution isn't sufficient in the face of VACUUM > FULL and mixed DML/DDL transaction that have not yet been decoded. > > To reiterate, as published it works like: > For every modification of catalog tuple (insert, multi_insert, update, > delete) that has influence over visibility issue a record that contains: > * filenode > * ctid > * (cmin, cmax) > > When doing a visibility check on a catalog row during decoding of mixed > DML/DDL transaction lookup (cmin, cmax) for that row since we don't > store both for the tuple. > > That mostly works great. > > The problematic scenario is decoding a transaction that has done mixed > DML/DDL *after* a VACUUM FULL/CLUSTER has been performed. The VACUUM > FULL obviously changes the filenode and the ctid of a tuple, so we > cannot successfully do a lookup based on what we logged before.
So I have a new idea for handling this problem, which seems obvious in retrospect. What if we make the VACUUM FULL or CLUSTER log the old CTID -> new CTID mappings? This would only need to be done for catalog tables, and maybe could be skipped for tuples whose XIDs are old enough that we know those transactions must already be decoded. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers