Re: ReadRecentBuffer() doesn't scale well - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: ReadRecentBuffer() doesn't scale well
Date
Msg-id CA+hUKGKkAOAb53tfWVJ_a+x=y=mf3pHv2nj=VzNHHOYP90vSwQ@mail.gmail.com
Whole thread Raw
In response to Re: ReadRecentBuffer() doesn't scale well  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: ReadRecentBuffer() doesn't scale well
Re: ReadRecentBuffer() doesn't scale well
List pgsql-hackers
On Tue, Jun 27, 2023 at 4:32 PM Peter Geoghegan <pg@bowt.ie> wrote:
> On Mon, Jun 26, 2023 at 9:09 PM Andres Freund <andres@anarazel.de> wrote:
> > I think we should be able to have a post-check that can figure out
> > if the copied root page is out of date after searching it, without needing the
> > content lock.
>
> I'm guessing that you're thinking of doing something with the page LSN?

If the goal is to get rid of both pins and content locks, LSN isn't
enough.  A page might be evicted and replaced by another page that has
the same LSN because they were modified by the same record.  Maybe
that's vanishingly rare, but the correct thing would be counter that
goes up on modification AND eviction.  (FWIW I toyed with variants of
this concept in the context of SLRU -> buffer pool migration, where I
was trying to do zero-lock CLOG lookups; in that case I didn't need
the copy of the page being discussed here due to the data being
atomically readable, but I had the same requirement for a
"did-it-change-under-my-feet?" check).



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: ReadRecentBuffer() doesn't scale well
Next
From: Peter Geoghegan
Date:
Subject: Re: ReadRecentBuffer() doesn't scale well