From: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Implement waiting for wal lsn replay: reloaded |
Date: | 2025-09-14 13:51:21 |
Message-ID: | CABPTF7V3TCo0RpPTUtVQ_30WfkUpfUyzWsbmeegkit0p6M=ZPA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Alexander,
On Sun, Sep 14, 2025 at 3:31 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>
> Hi, Xuneng!
>
> On Wed, Aug 27, 2025 at 6:54 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> > I did a rebase for the patch to v8 and incorporated a few changes:
> >
> > 1) Updated documentation, added new tests, and applied minor code
> > adjustments based on prior review comments.
> > 2) Tweaked the initialization of waitReplayLSNState so that
> > non-backend processes can call wait for replay.
> >
> > Started a new thread [1] and attached a patch addressing the polling
> > issue in the function
> > read_local_xlog_page_guts built on the infra of patch v8.
> >
> > [1] https://www.postgresql.org/message-id/CABPTF7Vr99gZ5GM_ZYbYnd9MMnoVW3pukBEviVoHKRvJW-dE3g@mail.gmail.com
> >
> > Feedbacks welcome.
>
> Thank you for your reviewing and revising this patch.
>
> I see you've integrated most of your points expressed in [1]. I went
> though them and I've integrated the rest of them. Except this one.
>
> > 11) The synopsis might read more clearly as:
> > - WAIT FOR LSN '<lsn>' [ TIMEOUT <milliseconds | 'duration-with-units'> ] [ NO_THROW ]
>
> I didn't find examples on how we do the similar things on other places
> of docs. This is why I decided to leave this place as it currently
> is.
+1. I re-check other commands with similar parameter patterns, and
they follow the approach in v9.
>
> Also, I found some mess up with typedefs.list. I've returned the
> changes to typdefs.list back and re-indented the sources.
Thanks for catching and fixing that.
> I'd like to ask your opinion of the way this feature is implemented in
> terms of grammar: generic parsing implemented in gram.y and the rest
> is done in wait.c. I think this approach should minimize additional
> keywords and states for parsing code. This comes at the price of more
> complex code in wait.c, but I think this is a fair price.
It's LGTM. The same pattern is observed in VACUUM, EXPLAIN, and CREATE
PUBLICATION - all use minimal grammar rules that produce generic
option lists, with the actual interpretation done in their respective
implementation files. The moderate complexity in wait.c seems
acceptable.
Best,
Xuneng
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2025-09-14 13:57:54 | Re: PostgreSQL 18 GA press release draft |
Previous Message | Jonathan S. Katz | 2025-09-14 13:41:30 | Re: PostgreSQL 18 GA press release draft |