> On 08 Apr 2016, at 16:09, Stas Kelvich <s.kelvich@postgrespro.ru> wrote:
>
> Tried on linux and os x 10.11 and 10.4.
>
> Still can’t reproduce, but have played around with your backtrace.
>
> I see in xlodump on slave following sequence of records:
>
> rmgr: Storage len (rec/tot): 16/ 42, tx: 0, lsn: 0/03015AF0, prev 0/03015958, desc: CREATE
base/12669/16387
> rmgr: Heap len (rec/tot): 3/ 1518, tx: 867, lsn: 0/03015B20, prev 0/03015AF0, desc: INSERT off 8,
blkref#0: rel 1663/12669/1247 blk 8 FPW
> <...>
> rmgr: Btree len (rec/tot): 2/ 72, tx: 867, lsn: 0/03019CD0, prev 0/03019C88, desc: INSERT_LEAF
off114, blkref #0: rel 1663/12669/2674 blk 22
> rmgr: Standby len (rec/tot): 16/ 42, tx: 867, lsn: 0/03019D18, prev 0/03019CD0, desc: LOCK xid 867
db12669 rel 16387
> rmgr: Transaction len (rec/tot): 784/ 813, tx: 867, lsn: 0/03019D48, prev 0/03019D18, desc: PREPARE
> rmgr: Transaction len (rec/tot): 380/ 409, tx: 0, lsn: 0/0301A090, prev 0/03019D48, desc:
COMMIT_PREPARED867: 2016-04-08 14:38:33.347851 MSK;
>
> It looks like that you had stuck in LOCK xid 867 even before replaying PREPARE record, so I have not that much ideas
onwhy that can be caused by changing procedures of PREPARE replay.
>
> Just to keep things sane, here is my current diff:
>
> <twophase_replay.v4.patch>
Michael, it looks like that you are the only one person who can reproduce that bug. I’ve tried on bunch of OS’s and
didn’tobserve that behaviour, also looking at your backtraces I can’t get who is holding this lock (and all of that
happensbefore first prepare record is replayed).
Can you investigate it more? Particularly find out who holds the lock?
There is last version of the patch:
--
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
