Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted
Date
Msg-id CAH2-WzkSCUXR9s2CVFLpbjmkXcQAE4QHyL8LkUGaKqSUgzEX-Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted  (Jeff Janes <jeff.janes@gmail.com>)
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ./configure fails for --host=i686-w64-mingw32 on Ubuntu
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] SERIALIZABLE on standby servers