From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Nikhil Sontakke <nikhils(at)2ndquadrant(dot)com> |
Cc: | David Steele <david(at)pgmasters(dot)net>, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Speedup twophase transactions |
Date: | 2017-03-16 12:25:55 |
Message-ID: | CAB7nPqTmpXohB+T4Q2dZcQPqL4y+OZPx0LKn-X_NEcbbaiJmkw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 16, 2017 at 7:18 PM, Nikhil Sontakke
<nikhils(at)2ndquadrant(dot)com> wrote:
>> + * * RecoverPreparedTransactions(),
>> StandbyRecoverPreparedTransactions()
>> + * and PrescanPreparedTransactions() have been modified to go
>> throug
>> + * gxact->inredo entries that have not made to disk yet.
>>
>> It seems to me that there should be an initial scan of pg_twophase at
>> the beginning of recovery, discarding on the way with a WARNING
>> entries that are older than the checkpoint redo horizon. This should
>> fill in shmem entries using something close to PrepareRedoAdd(), and
>> mark those entries as inredo. Then, at the end of recovery,
>> PrescanPreparedTransactions does not need to look at the entries in
>> pg_twophase. And that's the case as well of
>> RecoverPreparedTransaction(). I think that you could get the patch
>> much simplified this way, as any 2PC data can be fetched directly from
>> WAL segments and there is no need to rely on scans of pg_twophase,
>> this is replaced by scans of entries in TwoPhaseState.
>>
>
> 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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2017-03-16 12:26:46 | Re: Parallel Bitmap scans a bit broken |
Previous Message | Petr Jelinek | 2017-03-16 12:00:54 | Re: [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver |