Re: logical changeset generation v6.5
От | Steve Singer |
---|---|
Тема | Re: logical changeset generation v6.5 |
Дата | |
Msg-id | BLU0-SMTP951FDD7F334DF92F4E3832DCFD0@phx.gbl обсуждение исходный текст |
Ответ на | Re: logical changeset generation v6.5 (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: logical changeset generation v6.5
|
Список | 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 по дате отправления: