Re: Logical Replication of sequences
От | Nisha Moond |
---|---|
Тема | Re: Logical Replication of sequences |
Дата | |
Msg-id | CABdArM5earU8j1cBenw=h9vVMiPdyRPuh2djWsOyA+NFOy2sxA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical Replication of sequences (Peter Smith <smithpb2250@gmail.com>) |
Список | pgsql-hackers |
On Tue, May 20, 2025 at 8:35 AM Nisha Moond <nisha.moond412@gmail.com> wrote: > > > > > Thanks for the comments, these are handled in the attached v20250516 > > version patch. > > > > Thanks for the patches. Here are my review comments - > > Patch-0004: src/backend/replication/logical/sequencesync.c > Hi, Currently, the behavior of the internal query used to fetch sequence info from the pub is inconsistent and potentially misleading. case1: If a single non-existent sequence is passed (e.g., VALUES ('public','n10')), the query throws an ERROR, so we get error on sub - ERROR: could not receive list of sequence information from the publisher: ERROR: sequence "public.n10" does not exist case2: If multiple non-existent sequences are passed (e.g., VALUES ('public','n8'),('public','n9')), it silently returns zero rows, resulting only in a LOG message instead of an error. LOG: Logical replication sequence synchronization for subscription "subs" - total unsynchronized: 2; batch #1 = 2 attempted, 0 succeeded, 0 mismatched IMO, This inconsistency can be confusing for users. I think we should make the behavior uniform. Either - (a) Raise an error if any/all of the requested sequences are missing on the publisher, or (b) Instead of raising an error, emit a LOG(as is done in case2) and maybe include the count of missing sequences too. I'm fine with either option. -- Thanks, Nisha
В списке pgsql-hackers по дате отправления: