Re: logical changeset generation v6.5

From: Steve Singer <steve(at)ssinger(dot)info>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: logical changeset generation v6.5
Date: 2013-11-10 19:45:17
Message-ID: BLU0-SMTP71FF1104B12A9BC3055590DCFC0@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-11-10 19:55:26 pgsql: Fix whitespace issues found by git diff --check, add gitattribut
Previous Message Tom Lane 2013-11-10 19:28:22 Re: Any reasons to not move pgstattuple to core?