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

  1. Fix broken cleanup interlock for GIN pending list.

  2. Prevent multiple cleanup process for pending list in GIN.

  3. Add pages deleted from pending list to FSM

  4. Fix race condition in GIN posting tree page deletion.