Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-11-16T20:49:21Z
Lists: pgsql-hackers
On Thu, Nov 16, 2017 at 12:44 PM, Robert Haas <robertmhaas@gmail.com> wrote: > I would like to get rid of that LockPage() call, for sure, because > it's problematic in terms of allowing writes in parallel mode. > However, I think the reason here is the same as why the hash AM used > to use them. If you use a buffer lock, you really can't -- or > shoudn't, at least -- hold it across a whole series of operations, > because anyone waiting for that lock is waiting *uninterruptibly*. I'm well aware of that. > The hash AM wanted to iterate through all of the pages in a bucket > chain and do something to each one while preventing concurrent scans; > the need here is similar. Aside from the uninterruptible-wait > problem, such coding patterns are extremely prone to deadlock. If > there's any chance that a process waiting for the buffer lock you hold > might be holding a buffer lock you try to acquire, you have got a > problem. But there is only ever one page locked, the meta-page. And, it's always an ExclusiveLock. I don't see much use for deadlock avoidance. In any case, it's unusual to have a patch that uses LockPage() without explaining the choice. -- Peter Geoghegan
Commits
-
Fix broken cleanup interlock for GIN pending list.
- 19648ce55336 9.6.7 landed
- c8df4831ef21 10.2 landed
- 3b2787e1f8f1 11.0 landed
-
Prevent multiple cleanup process for pending list in GIN.
- e2c79e14d998 9.6.0 cited
-
Add pages deleted from pending list to FSM
- e95680832854 9.6.0 cited
-
Fix race condition in GIN posting tree page deletion.
- ac4ab97ec05e 9.4.0 cited