Horton

Re: Race condition in TransactionIdIsInProgress

Simon Riggs <simon.riggs@enterprisedb.com>

View thread View on postgr.es
From: Simon Riggs <simon.riggs@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Konstantin Knizhnik <knizhnik@garret.ru>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2022-02-11T13:48:59Z
Lists: pgsql-hackers

Attachments

On Fri, 11 Feb 2022 at 08:48, Simon Riggs <simon.riggs@enterprisedb.com> wrote:
>
> On Fri, 11 Feb 2022 at 06:11, Andres Freund <andres@anarazel.de> wrote:
>
> > Looks lik syncrep will make this a lot worse, because it can drastically
> > increase the window between the TransactionIdCommitTree() and
> > ProcArrayEndTransaction() due to the SyncRepWaitForLSN() inbetween.  But at
> > least it might make it easier to write tests exercising this scenario...
>
> Agreed
>
> TransactionIdIsKnownCompleted(xid) is only broken because the single
> item cache is set too early in some cases. The single item cache is
> important for performance, so we just need to be more careful about
> setting the cache.

Something like this... fix_cachedFetchXid.v1.patch prevents the cache
being set, but this fails! Not worked out why, yet.

just_remove_TransactionIdIsKnownCompleted_call.v1.patch
just removes the known offending call, passes make check, but IMHO
leaves the same error just as likely by other callers.

-- 
Simon Riggs                http://www.EnterpriseDB.com/

Commits

  1. Fix visibility check when XID is committed in CLOG but not in procarray.

  2. Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD while pruning.

  3. Make TransactionIdIsInProgress check transam.c's single-item XID status cache