On Wed, May 8, 2019 at 4:50 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Wed, May 8, 2019 at 3:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Thomas Munro <thomas.munro@gmail.com> writes:
> > > Reproduced here. Once the system reaches a state where it's leaking
> > > (which happens only occasionally for me during installcheck-parallel),
> > > it keeps leaking for future SSI transactions. The cause is
> > > SxactGlobalXmin getting stuck. The attached fixes it for me. I can't
> > > remember why on earth I made that change, but it is quite clearly
> > > wrong: you have to check every transaction, or you might never advance
> > > SxactGlobalXmin.
I pushed a version of that, thereby reverting the already-analysed
hunk, and also another similar hunk (probably harmless).
The second hunk dates from a time in development when I was treating
the final clean-up at commit time as a regular commit, but that failed
in PreCommit_CheckForSerializationFailure() because the DOOMED flag
was set by the earlier RO_SAFE partial release. The change was no
longer necessary, because final release of a partially released
read-only transaction is now done with isCommit forced to false.
(Before bb16aba50, it was done directly at RO_SAFE release time with
isCommit set to false, but bb16aba50 split the operation into two
phases, partial and then final, due to the extended object lifetime
requirement when sharing the SERIALIZABLEXACT with parallel workers.)
I'll update the open items page.
--
Thomas Munro
https://enterprisedb.com