On 11/09/2013 05:42 PM, Andres Freund wrote:
On 2013-11-09 17:36:49 -0500, Steve Singer wrote:
On 11/05/2013 10:21 AM, Andres Freund wrote:

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
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).
I've pushed an updated tree to git, that contains that

and some more fixes. I'll send out an email with details sometime soon.


Still give me the following:
update  disorder.do_inventory set ii_in_stock=2 where ii_id=251;
test1=# LOG:  tuple in table with oid: 35122 without primary key

\d disorder.do_inventory
   Table "disorder.do_inventory"
    Column     |  Type  | Modifiers
 ii_id         | bigint | not null
 ii_in_stock   | bigint |
 ii_reserved   | bigint |
 ii_total_sold | bigint |
    "do_inventory_pkey" PRIMARY KEY, btree (ii_id)
Foreign-key constraints:
"do_inventory_item_ref" FOREIGN KEY (ii_id) REFERENCES disorder.do_item(i_id) ON DELETE CASCADE
Referenced by:
TABLE "disorder.do_item" CONSTRAINT "do_item_inventory_ref" FOREIGN KEY (i_id) REFERENCES disorder.do_inventory(ii_id) DEFERRABLE INITIALLY DEFERRED TABLE "disorder.do_restock" CONSTRAINT "do_restock_inventory_ref" FOREIGN KEY (r_i_id) REFERENCES disorder.do_inventory(ii_id) ON DELETE CASCADE
_disorder_replica_truncatetrigger BEFORE TRUNCATE ON disorder.do_inventory FOR EACH STATEMENT EXECUTE PROCEDURE _disorder_replica.log_truncate('3')
Disabled triggers:
_disorder_replica_denyaccess BEFORE INSERT OR DELETE OR UPDATE ON disorder.do_inventory FOR EACH ROW EXECUTE PROCEDURE _disorder_replica.denyaccess('_disorder_replica') _disorder_replica_truncatedeny BEFORE TRUNCATE ON disorder.do_inventory FOR EACH STATEMENT EXECUTE PROCEDURE _disorder_replica.deny_truncate()
Replica Identity: FULL

The test decoder plugin gives me:

table "do_inventory": UPDATE: old-pkey:

a) The table does have a primary key
b) I don't get anything in the old key when I was expecting all the rows
c)  If I change the table to use the pkey index with
alter table disorder.do_inventory replica identity using index do_inventory_pkey;

The LOG message on the update goes away but the output of the test decoder plugin goes back to

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

Which I suspect means oldtuple is back to null


Andres Freund

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to