Re: Speedup twophase transactions

From: Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>
Subject: Re: Speedup twophase transactions
Date: 2016-04-11 10:16:37
Message-ID: C041D5B7-9779-46DB-8A31-4BDA45C2E3C5@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

> On 08 Apr 2016, at 16:09, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)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:

Attachment Content-Type Size
twophase_replay.v4.patch application/octet-stream 31.4 KB
unknown_filename text/plain 95 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-04-11 11:09:18 Re: [COMMITTERS] pgsql: Move each SLRU's lwlocks to a separate tranche.
Previous Message Magnus Hagander 2016-04-11 09:22:27 Re: Updated backup APIs for non-exclusive backups