Re: ReadRecentBuffer() doesn't scale well

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ReadRecentBuffer() doesn't scale well
Date: 2023-06-27 04:40:08
Message-ID: CA+hUKGKkAOAb53tfWVJ_a+x=y=mf3pHv2nj=VzNHHOYP90vSwQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 27, 2023 at 4:32 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Mon, Jun 26, 2023 at 9:09 PM Andres Freund <andres(at)anarazel(dot)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).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2023-06-27 04:53:12 Re: ReadRecentBuffer() doesn't scale well
Previous Message Peter Geoghegan 2023-06-27 04:32:22 Re: ReadRecentBuffer() doesn't scale well