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 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: