Re: Simplify code building the LR conflict messages

On Fri, Nov 28, 2025 at 6:38 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> So, what we're doing here is to append further row-identifying details
> to an errdetail string that already contains some explanation of the
> problem. That is, we have something like
>
> DETAIL: The row to be updated was deleted.
>
> and then we add whatever this function produces, after a newline. I
> don't remember any other place in our code that does such a thing. The
> result would look something like
>
> DETAIL: The row to be updated was deleted.
> Key: (1, 2); remote row (1,2,3); replica identity full (1,2,3).
>
> or something like that, where each of the parts can begin with uppercase
> or not, with a semicolon or not, depending on whether there are any
> previous parts.
>
> I wonder if it would make more sense to move this identifying
> information to a CONTEXT line instead, where we won't have to care about
> the uppercase.
>

As per my understanding, we typically display the information in
context via errcontext() in error context callback functions which may
not be immediately available at the location where error happens. For
example, while applying the remote changes, the error can happen
anywhere in the heap or below layer, but we add additional apply
related information (like which apply_message was being processed when
error occurred) via apply_error_callback. So, it is not clear in the
case at hand whether we should display the information which is
available at error_site via context message.

--
With Regards,
Amit Kapila.