Re: Add max_wal_replay_size connection parameter to libpq

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add max_wal_replay_size connection parameter to libpq
Date: 2026-03-30 07:45:07
Message-ID: bb22a05b-b033-4b71-b771-0ca6efd6abf1@uni-muenster.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Maksim.Melnikov 2026-03-30 07:56:02 Re: Fix race with LLVM and bison.
Previous Message Hayato Kuroda (Fujitsu) 2026-03-30 07:42:46 RE: Initial COPY of Logical Replication is too slow