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
> 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
> 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
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: