Message-ID: <bb22a05b-b033-4b71-b771-0ca6efd6abf1@uni-muenster.de>
Date: Mon, 30 Mar 2026 09:45:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Add max_wal_replay_size connection parameter to libpq
To: SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <126eb1e4-d98e-4647-b629-517adbcad28e@uni-muenster.de>
 <CAHg+QDeO4cbOKJSx0+yzD00a_1xv_z9dLrE4nKkxb1A+KEoKeg@mail.gmail.com>
 <dc1280a7-2033-4790-b147-babf55ae52f2@uni-muenster.de>
 <CAHg+QDffk2NSTTvobAqqBmpN+DTZDJ3cdwsi5XxOUmY-MdKgwA@mail.gmail.com>
Content-Language: de-DE, en-GB
From: Jim Jones <jim.jones@uni-muenster.de>
In-Reply-To: 
 <CAHg+QDffk2NSTTvobAqqBmpN+DTZDJ3cdwsi5XxOUmY-MdKgwA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/bb22a05b-b033-4b71-b771-0ca6efd6abf1%40uni-muenster.de>
Precedence: bulk

Hi Satya

On 30/03/2026 01:51, SATYANARAYANA NARLAPURAM wrote:
> 
> What is the expectation from such a routing? Is it for freshness of data
> for the client or 
> freeing up the standby  from user connections so that it can catch up
> with primary?
> The paragraph described originally was talking about the freshness.

The motivation is closer to the former, but in a specific sense. The
concrete situations I have in mind are:

* Standbys that are I/O-bound and falling behind on replaying received WAL
* Standbys catching up after a pause
* Standbys running with recovery_min_apply_delay (intentionally delayed
replication).

In these cases, the client would read data older than what the standby
has already received. Routing around them is what the parameter enables.
The parameter does not measure how far the standby is behind the primary
-- it only measures locally buffered WAL that hasn't been applied yet. I
see I should have been clearer about that in the original email.

Let me know if I am missing something here.

Thanks!

Best, Jim