Re: logical changeset generation v6.5 - Mailing list pgsql-hackers

From Steve Singer
Subject Re: logical changeset generation v6.5
Date
Msg-id BLU0-SMTP951FDD7F334DF92F4E3832DCFD0@phx.gbl
Whole thread Raw
In response to Re: logical changeset generation v6.5  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: logical changeset generation v6.5
List pgsql-hackers
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
>
>
>




pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Fw: [COMMITTERS] pgsql: Fix blatantly broken record_image_cmp() logic for pass-by-value
Next
From: Andres Freund
Date:
Subject: Re: logical changeset generation v6.5