Re: logical changeset generation v6.5

On 11/05/2013 10:21 AM, Andres Freund wrote:
> Hi,
>
> Attached to this mail and in the xlog-decoding-rebasing-remapping branch
> in my git[1] repository you can find the next version of the patchset that:
> * Fixes full table rewrites of catalog tables using the method Robert
> prefers (which is to log rewrite mappings to disk)
> * Extract the REPLICA IDENTITY as configured with ALTER TABLE for the
> old tuple for UPDATEs and DELETEs
> * Much better support for synchronous replication
> * Better resource cleanup (as in we need less local WAL available)
> * Lots of smaller fixes
> The change around REPLICA IDENTITY is *incompatible* to older output
> plugins since we now log tuples using the table's TupleDesc, not the
> indexes.

My updated plugin is getting rows with
change->tp.oldtuple as NULL on updates either with the default PRIMARY
KEY identify or with a FULL identity.

When I try the test_decoding plugin on UPDATE I get rows like:

table "do_inventory": UPDATE: ii_id[int8]:251 ii_in_stock[int8]:1
ii_reserved[int8]:144 ii_total_sold[int8]:911

which I think is only data from the new tuple. The lack of "old-key"
in the output makes me think the test decoding plugin also isn't getting
the old tuple.

(This is with your patch-set rebased ontop of
ac4ab97ec05ea900db0f14d428cae2e79832e02d which includes the patches
Robert committed the other day, I can't rule out that I didn't break
something in the rebase).

> Robert, I'd be very grateful if you could have a look at patch 0007
> implementing what we've discussed. I kept it separate to make it easier
> to look at it in isolation, but I think in the end it partially should
> be merged into the wal_level=logical patch.
> I still think the "wide cmin/cmax" solution is more elegant and has
> wider applicability, but this works as well although it's about 5 times
> the code.
>
> Comments?
>
> [1]: http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=summary
> Greetings,
>
> Andres Freund
>
>
>