Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
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-17T19:21:55Z
Lists: pgsql-hackers
On Wed, Aug 17, 2022 at 2:45 PM Andres Freund <andres@anarazel.de> wrote: > 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. There's not a horde of people lining up to work on the hash index code, but if you feel like writing and testing the more invasive fix, I'm not really going to fight you over it. -- Robert Haas EDB: http://www.enterprisedb.com
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