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: David Steele <david(at)pgmasters(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>
Subject: Re: Speedup twophase transactions
Date: 2016-04-08 13:09:23
Message-ID: 6E7C0402-6167-4476-ADE8-3E3BD687743C@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

> On 07 Apr 2016, at 09:29, Michael Paquier <michael(dot)paquier(at)gmail(dot)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:

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 Rushabh Lathia 2016-04-08 13:21:23 Re: Optimization for updating foreign tables in Postgres FDW
Previous Message Andrew Dunstan 2016-04-08 13:05:34 Re: VS 2015 support in src/tools/msvc