Re: [HACKERS] Speedup twophase transactions - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Speedup twophase transactions
Date
Msg-id CAB7nPqSC+xWsH=AXmdT5xL-ixi2cpCJh4WKkkGhxsUaeRqWGdA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Speedup twophase transactions  (Nikhil Sontakke <nikhils@2ndquadrant.com>)
Responses Re: [HACKERS] Speedup twophase transactions  (Nikhil Sontakke <nikhils@2ndquadrant.com>)
List pgsql-hackers
On Fri, Mar 17, 2017 at 4:42 PM, Nikhil Sontakke
<nikhils@2ndquadrant.com> wrote:
>> >
>> > I don't think this will work. We cannot replace pg_twophase with shmem
>> > entries + WAL pointers. This is because we cannot expect to have WAL
>> > entries
>> > around for long running prepared queries which survive across
>> > checkpoints.
>>
>> But at the beginning of recovery, we can mark such entries with ondisk
>> and inredo, in which case the WAL pointers stored in the shmem entries
>> do not matter because the data is already on disk.
>
> Ok, we can do that and then yes, RecoverPreparedTransaction() can just have
> one loop going through the shmem entries. BUT, we cannot ignore
> "inredo"+"ondisk" entries. For such entries, we will have to read and
> recover from the corresponding 2PC files.

Yes. About other things I found... In CheckPointTwoPhase(), I am
actually surprised that prepare_start_lsn and prepare_end_lsn are not
reset to InvalidXLogRecPtr when a shmem entry is flushed to disk after
ondisk is set to true, there is no need for them as the data does not
need to be fetched from WAL segments so we had better be consistent
(regression tests fail if I do that). And the two extra arguments in
MarkAsPreparing() are really unnecessary, they get set all the time to
InvalidXLogRecPtr.
-- 
Michael



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] IF (NOT) EXISTS in psql-completion