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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
