Re: Sending unflushed WAL in physical replication

From: Rahila Syed <rahilasyed90(at)gmail(dot)com>
To: Aleksander Alekseev <aleksander(at)tigerdata(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>
Subject: Re: Sending unflushed WAL in physical replication
Date: 2025-09-30 10:08:01
Message-ID: CAH2L28usoyAnwS5y51ukuaXdrp2WDZGMXFbTVXMFTJmOZxv=FA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

> > Please find attached a POC patch that introduces changes to the WAL
> sender and
> > receiver, allowing WAL records to be sent to standbys before they are
> flushed
> > to disk on the primary during physical replication. [..]
>
> I didn't look at the code but your description of the design sounds OK.
>
>
Thanks for looking into it.

> I wanted to clarify: what happens if master doesn't increase flushPtr
> and replica runs out of memory for WAL records?
>

This is a great question. I'm currently working on implementing a solution
for this.
One possible solution is to write the records to a spill file when the
flush pointer
indicates that none have been flushed on the primary. Once they have been
flushed
on the primary, the records can then be copied from the spill file to the
WAL segments.
While this method may lead to increased I/O, if such spills are infrequent,
the overall
performance impact should be minimal.

Another option would be to notify the sender that there is no more space
available
and to pause sending additional data until records are flushed on the
sender side.
However, this approach could reintroduce some of the replication lag or
network
latency that we are aiming to minimize.

Kindly let me know your views.

Thank you,
Rahila Syed

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2025-09-30 10:13:57 Re: relfilenode statistics
Previous Message Bertrand Drouvot 2025-09-30 10:05:43 Re: [BUG]: the walsender does not update its IO statistics until it exits