Re: Implement waiting for wal lsn replay: reloaded
От | Xuneng Zhou |
---|---|
Тема | Re: Implement waiting for wal lsn replay: reloaded |
Дата | |
Msg-id | CABPTF7X7HcGnPAg6UShHnaX_SA6Tcw5ND2y7c1kiSUpqdXE8Ag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Implement waiting for wal lsn replay: reloaded (Álvaro Herrera <alvherre@kurilemu.de>) |
Ответы |
Re: Implement waiting for wal lsn replay: reloaded
|
Список | pgsql-hackers |
Hi Álvaro, Thanks for your review. On Tue, Sep 16, 2025 at 4:24 AM Álvaro Herrera <alvherre@kurilemu.de> wrote: > > On 2025-Sep-15, Alexander Korotkov wrote: > > > > 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. > > Actually I find the code in ExecWaitStmt pretty unusual. We tend to use > lists of DefElem (a name optionally followed by a value) instead of > individual scattered elements that must later be matched up. Why not > use utility_option_list instead and then loop on the list of DefElems? > It'd be a lot simpler. I took a look at commands like VACUUM and EXPLAIN and they do follow this pattern. v11 will make use of utility_option_list. > Also, we've found that failing to surround the options by parens leads > to pain down the road, so maybe add that. Given that the LSN seems to > be mandatory, maybe make it something like > > WAIT FOR LSN 'xy/zzy' [ WITH ( utility_option_list ) ] > > This requires that you make LSN a keyword, albeit unreserved. Or you > could make it > WAIT FOR Ident [the rest] > and then ensure in C that the identifier matches the word LSN, such as > we do for "permissive" and "restrictive" in > RowSecurityDefaultPermissive. Shall make LSN an unreserved keyword as well. Best, Xuneng
В списке pgsql-hackers по дате отправления: