On Fri, Nov 28, 2025 at 6:38 PM Álvaro Herrera <[email protected]> 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.
