public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jim Jones <[email protected]>
To: SATYANARAYANA NARLAPURAM <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Add max_wal_replay_size connection parameter to libpq
Date: Sun, 29 Mar 2026 20:53:46 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAHg+QDeO4cbOKJSx0+yzD00a_1xv_z9dLrE4nKkxb1A+KEoKeg@mail.gmail.com>
References: <[email protected]>
	<CAHg+QDeO4cbOKJSx0+yzD00a_1xv_z9dLrE4nKkxb1A+KEoKeg@mail.gmail.com>



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

view thread (4+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Add max_wal_replay_size connection parameter to libpq
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox