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

From Michael Paquier
Subject Re: [HACKERS] Speedup twophase transactions
Date
Msg-id CAB7nPqR+U+R3NMDmOJgGmFwuqSBRnpk2mOxW5nCPVrU-bLsTfg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Speedup twophase transactions  (Stas Kelvich <s.kelvich@postgrespro.ru>)
Responses Re: [HACKERS] Speedup twophase transactions  (Stas Kelvich <s.kelvich@postgrespro.ru>)
List pgsql-hackers
On Fri, Dec 16, 2016 at 8:00 PM, Stas Kelvich <s.kelvich@postgrespro.ru> wrote:
> So, here is brand new implementation of the same thing.
>
> Now instead of creating pgproc entry for prepared transaction during
> recovery,
> I just store recptr/xid correspondence in separate 2L-list and deleting
> entries in that
> list if redo process faced commit/abort. In case of checkpoint or end of
> recovery
> transactions remaining in that list are dumped to files in pg_twophase.
>
> Seems that current approach is way more simpler and patch has two times less
> LOCs then previous one.

That's indeed way simpler than before. Have you as well looked at the
most simple approach discussed? That would be just roughly replacing
the pg_fsync() calls currently in RecreateTwoPhaseFile() by a save
into a list as you are doing, then issue them all checkpoint. Even for
2PC files that are created and then removed before the next
checkpoint, those will likely be in system cache. This removes as well
the need to have XlogReadTwoPhaseData() work in crash recovery, which
makes me a bit nervous. And this saves lookups at the WAL segments
still present in pg_xlog, making the operation at checkpoint much
faster with many 2PC files to process.
-- 
Michael



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Simplify LWLock tranche machinery by removing array_base/array_s
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Simplify LWLock tranche machinery by removing array_base/array_s