Re: Atomic GetFreeIndexPage()?

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Chris Cleveland <ccleveland(at)dieselpoint(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Atomic GetFreeIndexPage()?
Date: 2022-05-04 23:42:11
Message-ID: CAH2-Wzk1_VYtC8hfKTHFRuP5=zTgMzrgLZmZUT-zsXx00ASk-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 4, 2022 at 12:16 PM Chris Cleveland
<ccleveland(at)dieselpoint(dot)com> wrote:
> Similar code is repeated in a bunch of places. Each access method has to explicitly write something into a freed page that identifies it as ok to use.

I wouldn't say that that's what this code is doing, though I do see
what you mean. The reason why the ultimate consumer of the free page
writes to it is because....well, it wouldn't have asked for a page if
it didn't have something to write.

Code like GinPageIsRecyclable() is generally concerned with something
called recycle safety, typically using something called the drain
technique. That's what this code is primarily concerned about. The
definition of recycle safety is documented in the nbtree README.

> Otherwise, you could have two processes get the same page, then one locks it, writes it, and unlocks it, then the second one does the same clobbering the first.

But you could have that anyway, since the FSM isn't crash safe. It's
inherently not completely trustworthy for that reason.

Actually, the FSM shouldn't really contain a page that is !
GinPageIsRecyclable() to begin with, but that is still possible for a
variety of reasons. All of which boil down to "the current FSM design
cannot be totally trusted, so we verify redundantly".

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2022-05-05 03:24:19 Re: pg_stat_statements
Previous Message Tom Lane 2022-05-04 23:02:57 Re: Costing elided SubqueryScans more nearly correctly