Re: Improve read_local_xlog_page_guts by replacing polling with latch-based waiting

Hi,

On Sat, Oct 11, 2025 at 11:02 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
>
> Hi,
>
> The following is the split patch set. There are certain limitations to
> this simplification effort, particularly in patch 2. The
> read_local_xlog_page_guts callback demands more functionality from the
> facility than the WAIT FOR patch — specifically, it must wait for WAL
> flush events, though it does not require timeout handling. In some
> sense, parts of patch 3 can be viewed as a superset of the WAIT FOR
> patch, since it installs wake-up hooks in more locations. Unlike the
> WAIT FOR patch, which only needs wake-ups triggered by replay,
> read_local_xlog_page_guts must also handle wake-ups triggered by WAL
> flushes.
>
> Workload characteristics play a key role here. A sorted dlist performs
> well when insertions and removals occur in order, achieving O(1)
> complexity in the best case. In synchronous replication, insertion
> patterns seem generally monotonic with commit LSNs, though not
> strictly ordered due to timing variations and contention. When most
> insertions remain ordered, a dlist can be efficient. However, as the
> number of elements grows and out-of-order insertions become more
> frequent, the insertion cost can degrade to O(n) more often.
>
> By contrast, a pairing heap maintains stable O(1) insertion for both
> ordered and disordered inputs, with amortized O(log n) removals. Since
> LSNs in the WAIT FOR command are likely to arrive in a non-sequential
> fashion, the pairing heap introduced in v6 provides more predictable
> performance under such workloads.
>
> At this stage (v7), no consolidation between syncrep and xlogwait has
> been implemented. This is mainly because the dlist and pairing heap
> each works well under different workloads — neither is likely to be
> universally optimal. Introducing the facility with a pairing heap
> first seems reasonable, as it offers flexibility for future
> refactoring: we could later replace dlist with a heap or adopt a
> modular design depending on observed workload characteristics.
>

v8-0002 removed the early fast check before addLSNWaiter in WaitForLSNReplay,
as the likelihood of a server state change is small compared to the
branching cost and added code complexity.

Best,
Xuneng