Re: ReadRecentBuffer() doesn't scale well

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: ReadRecentBuffer() doesn't scale well
Дата
Msg-id 20230627053914.52frtj23gmvttext@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: ReadRecentBuffer() doesn't scale well  (Thomas Munro <thomas.munro@gmail.com>)
Список 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@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?

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Assert !bms_overlap(joinrel->relids, required_outer)
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [PATCH] Honor PG_TEST_NOCLEAN for tempdirs