Re: logical changeset generation v6.2

On Fri, Oct 18, 2013 at 2:26 PM, Andres Freund <andres(at)2ndquadrant(dot)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