Re: Conflict detection for update_deleted in logical replication
От | shveta malik |
---|---|
Тема | Re: Conflict detection for update_deleted in logical replication |
Дата | |
Msg-id | CAJpy0uCgEwT4dpoxELpz3706Q=EVs_W=B3kApOEGmViehVavZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Conflict detection for update_deleted in logical replication (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Tue, May 20, 2025 at 10:24 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Tue, May 20, 2025 at 8:38 AM shveta malik <shveta.malik@gmail.com> wrote: > > > > Please find few more comments: > > > > 1) > > ProcessStandbyPSRequestMessage: > > + /* > > + * This shouldn't happen because we don't support getting primary status > > + * message from standby. > > + */ > > + if (RecoveryInProgress()) > > + elog(ERROR, "the primary status is unavailable during recovery"); > > > > > > a) This error is not clear. Is it supposed to be user oriented error > > or internal error? As a user, it is difficult to interpret this error > > and take some action. > > > > This is an internal error for developers to understand that they have > sent the wrong message. Do you have any suggestions to change it? The current message is fine if point b) is already taken care of. > > > b) What I understood is that there is no user of enabling > > 'retain_conflict_info' for a subscription which is subscribing to a > > publisher which is physical standby too. So shall we emit such an > > ERROR during 'Create Sub(retain_conflict_info=on)' itself? But that > > would need checking whether the publisher is physical standby or not > > during CREATE-SUB. Is that a possibility? > > > > The 0003 patch already took care of this, see check_conflict_info_retaintion. > Okay, thanks. Missed it somehow during review. thanks Shveta
В списке pgsql-hackers по дате отправления: