> On 08 Apr 2016, at 16:09, Stas Kelvich <s.kelv...@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 off 114, 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 db 12669 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_PREPARED 867: 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 on why 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’t observe that behaviour, also looking at your backtraces I can’t get who is holding this lock (and all of that happens before first prepare record is replayed). Can you investigate it more? Particularly find out who holds the lock? There is last version of the patch:
twophase_replay.v4.patch
Description: Binary data
-- Stas Kelvich Postgres Professional: http://www.postgrespro.com Russian Postgres Company
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
