Re: Speedup twophase transactions

> On 07 Apr 2016, at 09:29, Michael Paquier <michael.paquier@gmail.com> wrote:
>
> relOid=16385) + 358 at standby.c:627
>    frame #11: 0x00000001023dac6b
> postgres`standby_redo(record=0x00007fde50841e38) + 251 at
> standby.c:809
>
> (LOCALLOCK) $1 = {
>  tag = {
>    lock = {
>      locktag_field1 = 16384
>      locktag_field2 = 16385
>      locktag_field3 = 0
>      locktag_field4 = 0
>      locktag_type = '\0'
>      locktag_lockmethodid = '\x01'
>    }
>    mode = 8
>  }
>
> =# select relname, oid from pg_class where oid > 16000;
> relname |  oid

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
12669rel 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
whythat can be caused by changing procedures of PREPARE replay. 

Just to keep things sane, here is my current diff:


--
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company