| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
| Cc: | Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Race condition in TransactionIdIsInProgress |
| Date: | 2022-02-11 06:11:38 |
| Message-ID: | 20220211061138.txztn7kjipie3pok@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | tanghy.fnst@fujitsu.com | 2022-02-11 06:30:45 | RE: [BUG]Update Toast data failure in logical replication |
| Previous Message | Andres Freund | 2022-02-11 05:56:09 | Re: Race condition in TransactionIdIsInProgress |