Message-ID: <dc1280a7-2033-4790-b147-babf55ae52f2@uni-muenster.de>
Date: Sun, 29 Mar 2026 20:53:46 +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>
Content-Language: de-DE, en-GB
From: Jim Jones <jim.jones@uni-muenster.de>
In-Reply-To: 
 <CAHg+QDeO4cbOKJSx0+yzD00a_1xv_z9dLrE4nKkxb1A+KEoKeg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/dc1280a7-2033-4790-b147-babf55ae52f2%40uni-muenster.de>
Precedence: bulk


On 29/03/2026 20:31, SATYANARAYANA NARLAPURAM wrote:
> What if none of them meets the criteria? You fail the connection?
> Wouldn't it cause an availability issue?


Yes, the connection fails if no host meets the threshold. This is
intentional, and it is consistent with the existing behaviour of
target_session_attrs: if you set target_session_attrs=standby and no
standby is reachable, the connection fails too.


>     If pg_last_wal_receive_lsn() is NULL (e.g. no active WAL receiver due to
>     missing primary_conninfo or a disconnected upstream), the backlog cannot
>     be determined. In that case, the standby is treated as exceeding the
>     threshold and is skipped.
> 
> 
> When a standby is replaying archiving log, it can still be caught up.
> This doesn't seem right to me.


I totally see your point here. The issue is that
pg_last_wal_receive_lsn() returns NULL when there is no WAL receiver
process -- regardless of how current the data actually is. Without a
receive LSN, the metric this parameter is based on (receive_lsn -
replay_lsn) is simply undefined for that standby.

Please let me know if I am missing something here.


> 
>     This parameter measures only the apply lag on the standby itself, i.e.,
>     how much already-received WAL remains to be replayed. It does not
>     attempt to measure how far the standby is behind the primary. In
>     particular, a standby that is slow to receive WAL but fast to replay it
>     may report a small backlog here while still being significantly behind.
> 
> 
> IMHO, this change appears to not meet the objective of routing
> connections/queries to the most up-to-date standby.


The parameter's objective is not to route to the most up-to-date
standby; it is to skip standbys whose apply lag exceeds a given threshold.

Thanks for the quick feedback. Much appreciated!

Best, Jim