On 2013-11-09 20:16:20 -0500, Steve Singer wrote: >>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
>
>http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/xlog-decoding-rebasing-remapping
> >git://git.postgresql.org/git/users/andresfreund/postgres.git
> >
> >and some more fixes. I'll send out an email with details sometime soon.
>
> 93c5c2a171455763995cef0afa907bcfaa405db4
>
> Still give me the following:
> update disorder.do_inventory set ii_in_stock=2 where ii_id=251;
> UPDATE 1
> test1=# LOG: tuple in table with oid: 35122 without primary key
Hm. Could it be that you still have an older "test_decoding" plugin
lying around? The current one doesn't contain that string
anymore. That'd explain the problems.
In v6.4 the output plugin API was changed that plain heaptuples are
passed for the "old" key, although with non-key columns set to
NULL. Earlier it was a "index tuple" as defined by the indexes
TupleDesc.
> 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
Which is legitimate though, if you don't update the primary (or
explicitly chosen candidate) key. Those only get logged if there's
actual changes in those columns.
Makes sense?
Greetings,
Andres Freund
--Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
