> 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