On 2016-03-04 12:36:32 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > Ugh, that's an annoying bug. Working on producing a fix.
> >
> > The problem is that logical decoding expects to know about toplevel xids
> > before subtransaction/savepoint xids. Which is enforced in the WAL
> > logging code, so that's ok. But the problem is that right now the WAL
> > produced looks like (abbreviated):
> > rmgr: Heap tx: 585, lsn: 0/01A304A8, desc: LOCK off 1: xid 585 LOCK_ONLY EXCL_LOCK KEYS_UPDATED ,
blkref#0: rel 1663/12385/24607 blk 0
> > rmgr: Heap tx: 586, lsn: 0/01A30658, desc: INSERT off 2, blkref #0: rel 1663/12385/24607 blk 0 FPW
> > rmgr: Transaction tx: 586, lsn: 0/01A30798, desc: ABORT 2016-02-07 12:21:18.624045 CET
> > rmgr: Standby tx: 0, lsn: 0/01A307C0, desc: RUNNING_XACTS nextXid 587 latestCompletedXid 586
oldestRunningXid585; 1 xacts: 585
> > rmgr: Heap tx: 587, lsn: 0/01A307F8, desc: INSERT off 3, blkref #0: rel 1663/12385/24607 blk 0
> > rmgr: Btree tx: 587, lsn: 0/01A30838, desc: INSERT_LEAF off 3, blkref #0: rel 1663/12385/24614 blk 1
> > rmgr: Transaction tx: 585, lsn: 0/01A30878, desc: COMMIT 2016-02-07 12:21:28.062978 CET; subxacts: 587
> >
> > and decode.c doesn't care about LOCK records so far. Which means
> > reorderbuffer.c doesn't know about the relevant xid. Hm.
>
> Any progress with this?
Yes. The attached WIP patch fixes this, and some other issues. I'm
working on splitting it up, and adding some more testcases.
Andres