| 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
| 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 |