Re: Improve WALRead() to suck data directly from WAL buffers when possible - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Improve WALRead() to suck data directly from WAL buffers when possible
Date
Msg-id ffd67cc0a7b6b4c06ad36967c4d7eb7825bf293a.camel@j-davis.com
Whole thread Raw
In response to Re: Improve WALRead() to suck data directly from WAL buffers when possible  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Improve WALRead() to suck data directly from WAL buffers when possible  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, 2024-02-12 at 11:33 -0800, Jeff Davis wrote:
> For 0002 & 0003, I'd like more clarity on how they will actually be
> used by an extension.

In patch 0002, I'm concerned about calling
WaitXLogInsertionsToFinish(). It loops through all the locks, but
doesn't have any early return path or advance any state.

So if it's repeatedly called with the same or similar values it seems
like it would be doing a lot of extra work.

I'm not sure of the best fix. We could add something to LogwrtResult to
track a new LSN that represents the highest known point where all
inserters are finished (in other words, the latest return value of
WaitXLogInsertionsToFinish()). That seems invasive, though.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: glibc qsort() vulnerability
Next
From: jian he
Date:
Subject: Re: POC, WIP: OR-clause support for indexes