> On 21 Sep 2016, at 10:32, Michael Paquier <michael.paqu...@gmail.com> wrote: > > On Tue, Sep 20, 2016 at 11:13 PM, Stas Kelvich <s.kelv...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
