| From: | Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> |
|---|---|
| To: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
| Cc: | Japin Li <japinli(at)hotmail(dot)com>, surya poondla <suryapoondla4(at)gmail(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication |
| Date: | 2026-04-07 05:50:41 |
| Message-ID: | CAE9k0PkXu_jy=tPKcFOd+P223Y327T91beF8bV75pUm01evnOQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Tue, Apr 7, 2026 at 9:04 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
>
> I see your point. I agree that using wal_receiver_status_interval for
> this test may not be a reliable way. Can we attempt using
> pg_wal_replay_pause() on standby and then checking
> wait_event=WaitForStandbyConfirmation with backend_type=walsender on
> primary? Or do you see any issues in this approach that I might be
> overlooking?
>
Yes, I think we can make use of the WAL replay pause/resume mechanism.
This seems like the right approach, as it gives us a more controlled
and deterministic way to validate the lagging behavior.
--
With Regards,
Ashutosh Sharma.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bertrand Drouvot | 2026-04-07 06:01:08 | Re: Adding locks statistics |
| Previous Message | Peter Smith | 2026-04-07 05:46:51 | Re: DOCS: typo on CLUSTER page |