Horton

Re: Race condition in TransactionIdIsInProgress

Andres Freund <andres@anarazel.de>

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

On 2022-02-10 21:56:09 -0800, Andres Freund wrote:
> I think this may actually mean that the hot corruption problem fixed in
> 
> commit 18b87b201f7
> Author: Andres Freund <andres@anarazel.de>
> Date:   2021-12-10 20:12:26 -0800
> 
>     Fix possible HOT corruption when RECENTLY_DEAD changes to DEAD while pruning.
> 
> for 14/master is present in older branches too :(. Need to trace through the
> HTSV and pruning logic with a bit more braincells than currently available to
> be sure.

On second thought, there's probably sufficiently more direct corruption this
can cause than corruption via hot pruning. Not that that's not a problem, but
... Inconsistent TransactionIdIsInProgress() result can wreak havoc quite
broadly.

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...

Greetings,

Andres Freund

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