Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Mark Dilger <mark.dilger@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>, Thomas Munro <thomas.munro@gmail.com>
Date: 2022-08-17T18:45:34Z
Lists: pgsql-hackers
Hi, On 2022-08-17 08:25:06 -0400, Robert Haas wrote: > Regarding the question of whether we need a cleanup lock on the new > bucket I am not really seeing the advantage of going down that path. > Simply fixing this code to take a cleanup lock instead of hoping that > it always gets one by accident is low risk and should fix the observed > problem. Getting rid of the cleanup lock will be more invasive and I'd > like to see some evidence that it's a necessary step before we take > the risk of breaking things. Given that the cleanup locks in question are "taken" *after* re-initializing the page, I'm doubtful that's a sane path forward. It seems quite likely to mislead somebody to rely on it working as a cleanup lock in the future. Greetings, Andres Freund
Commits
-
Fix cleanup lock acquisition in SPLIT_ALLOCATE_PAGE replay.
- e848be60b5cf 16.0 landed
- e49e191815b6 15.2 landed
- 9693f190076e 14.7 landed
- 20c223336301 13.10 landed
- 4dccccb37e0b 12.14 landed
- 1703033f896a 11.19 landed