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

From Andres Freund
Subject Re: logical changeset generation v6.5
Date
Msg-id 20131111190658.GM2401@awork2.anarazel.de
Whole thread Raw
In response to Re: logical changeset generation v6.5  (Steve Singer <steve@ssinger.info>)
Responses Re: logical changeset generation v6.5  (Steve Singer <steve@ssinger.info>)
List pgsql-hackers
On 2013-11-10 14:45:17 -0500, Steve Singer wrote:
> 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.

Heh, happened to me several times during development ;)

> >>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.

I'd expect them to check whether relreplident is FULL, NOTHING or
DEFAULT|INDEX. In the latter case they can check
Relation->rd_replidindex. The bitmap doesn't really seem to be helpful?

> How do we feel about having the decoder logic populate change.oldtuple with
> the identity  on UPDATE statements when it is null?

Not really keen - that'd be a noticeable overhead. Note that in the
cases where DEFAULT|INDEX is used, you can just use the new tuple to
extract what you need for the pkey lookup since they now have the same
format and since it's guaranteed that the relevant columns haven't
changed if oldtup is null and there's a key.

What are you actually doing with those columns? Populating a WHERE
clause?

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: better atomics - spinlock fallback?
Next
From: Peter Eisentraut
Date:
Subject: Re: [COMMITTERS] pgsql: Fix whitespace issues found by git diff --check, add gitattribut