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: Jeff Janes <jeff.janes@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-11-16T22:43:20Z
Lists: pgsql-hackers
On Thu, Nov 16, 2017 at 2:16 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> The only reference to super-exclusive lock in src/backend/access/gin/README,
> that I can find, is about posting trees, not pending lists.  Can you quote
> or give line numbers of the section you are referring to?

That's the section I was referring to. I apologize for being unclear.

I would like to see a *general* explanation of why it's okay that the
pending list can have its pages recycled early. How can we be sure
that somebody looking through the pending list won't land on a
just-recycled page and somehow get confused?

We see this for the entry tree (no deletion is possible in the first
place), and we also see it for the posting tree (the dance with
inserters having a pin on the root, and so on). Not mentioning why
pending list recycling is safe in terms of locking protocols seems
like an omission that should be addressed. I'm no GIN expert, but I
would expect this because the pending list seems like a kind of
extension of the posting tree.

As I've said, it feels slightly off to me that a user backend that is
performing opportunistic cleanup during insertion can call
RecordFreeIndexPage() in GIN.

-- 
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.