From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ReadRecentBuffer() doesn't scale well |
Date: | 2023-06-27 05:39:14 |
Message-ID: | 20230627053914.52frtj23gmvttext@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-06-27 16:40:08 +1200, Thomas Munro wrote:
> 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?
Yes, that seems to be the most obvious.
> If the goal is to get rid of both pins and content locks, LSN isn't
> enough.
I was imaginging you'd have a long-lived pin. I don't think trying to make it
work without that is particularly promising in this context, where it seems
quite feasible to keep pins around for a while.
> 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.
I don't think it would need to be a single counter. If we wanted to do
something like this, I think you'd have to have a counter in the buffer desc
that's incremented whenever the page is replaced. Plus the LSN for the page
content change "counter".
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-06-27 05:47:08 | Re: [PATCH] Honor PG_TEST_NOCLEAN for tempdirs |
Previous Message | Michael Paquier | 2023-06-27 05:35:19 | Re: Assert !bms_overlap(joinrel->relids, required_outer) |