Re: Conflict detection for update_deleted in logical replication - Mailing list pgsql-hackers

From shveta malik
Subject Re: Conflict detection for update_deleted in logical replication
Date
Msg-id CAJpy0uCgEwT4dpoxELpz3706Q=EVs_W=B3kApOEGmViehVavZQ@mail.gmail.com
Whole thread Raw
In response to Re: Conflict detection for update_deleted in logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
List 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 by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Adding null patch entry to cfbot/CommitFest
Next
From: Peter Smith
Date:
Subject: Re: Logical Replication of sequences