> On 21 Sep 2016, at 10:32, Michael Paquier <michael.paquier@gmail.com> wrote:
>
> On Tue, Sep 20, 2016 at 11:13 PM, Stas Kelvich <s.kelvich@postgrespro.ru> wrote:
>>
>> Putting that before actual WAL replay is just following historical order of events.
>> Prepared files are pieces of WAL that happened before checkpoint, so ISTM
>> there is no conceptual problem in restoring their state before replay.
>
> For wal_level = minimal there is no need to call that to begin with..
> And I'd think that it is better to continue with things the same way.
>
Hm, why?
>>
>> With this patch we are reusing one infrastructure for normal work, recovery and replay.
>
> The mix between normal work and recovery is the scary part. Normal
> work and recovery are entirely two different things.
>
Okay, agreed. Commit procedure that checks whether recovery is active or not
is quite hacky solution.
>> So taking into account my comments what do you think? Should we keep current approach
>> or try to avoid replaying prepare records at all?
>
> I'd really like to give a try to the idea you just mentioned, aka
> delay the fsync of the 2PC files from RecreateTwoPhaseFile to
> CreateRestartPoint, or get things into memory.. I could write one, or
> both of those patches. I don't mind.
I’m not giving up yet, i’ll write them) I still have in mind several other patches to 2pc handling in
postgres during this release cycle — logical decoding and partitioned hash instead of
TwoPhaseState list.
My bet that relative speed of that patches will depend on used filesystem. Like it was with the
first patch in that mail thread it is totally possible sometimes to hit filesystem limits on file
creation speed. Otherwise both approaches should be more or less equal, i suppose.
--
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company