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

From Steve Singer
Subject Re: logical changeset generation v6.5
Date
Msg-id BLU0-SMTP71FF1104B12A9BC3055590DCFC0@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  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 11/10/2013 09:41 AM, Andres Freund wrote:
> 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.

Grrr, yah that was the problem I had compiled but not installed the 
newer plugin. Sorry.


>> 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?
Is the expectation that plugin writters will call
RelationGetIndexAttrBitmap(relation,INDEX_ATTR_BITMAP_IDENTITY_KEY);
to figure out what the identity key is.

How do we feel about having the decoder logic populate change.oldtuple 
with the identity
on UPDATE statements when it is null?  The logic I have now is  to use 
oldtuple if it is not null, otherwise go figure out which columns from 
the identiy key we should be using.   I think most plugins that do 
anything useful with an update will need to duplicate that







> Greetings,
>
> Andres Freund
>
> --
>   Andres Freund                       http://www.2ndQuadrant.com/
>   PostgreSQL Development, 24x7 Support, Training & Services
>
>




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Any reasons to not move pgstattuple to core?
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Replace duplicate_oids with Perl implementation