| From: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | Dmytro Astapov <dastapov(at)gmail(dot)com>, Anthony Hsu <erwaman(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Set 1s WaitLatch timeout if standby limit has expired in ResolveRecoveryConflictWithBufferPin |
| Date: | 2026-11-11 04:28:57 |
| Message-ID: | CABPTF7UqWz=t7emtNX_LFknmgEbfy5Nxys=JSwj50GxnvWxbHg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 11, 2026 at 10:53 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> it's set. However, it seems to violate the promise of
> max_standby_*_delay to some extent -- the startup could be stalled
> further even if it has already expired.
After reading the doc of this parameter closely, this seems a bit
overstated -- it has no promise of freeing replay from stall...
When hot standby is active, this parameter determines how long the
standby server should wait before canceling standby queries that
conflict with about-to-be-applied WAL entries, as described in
<xref linkend="hot-standby-conflict"/>.
it does extend the "wait" to exceed the setting value if late pinners
keep coming. Nevertheless, this is just an imagination of the worst
case.
--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manu | 2026-11-11 04:54:29 | Re: REPACK enhancements |
| Previous Message | João Rito | 2026-11-11 04:11:13 | Re: Small fixes needed by high-availability tools |