On Thu, Jun 12, 2025 at 3:09 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > cases like UPDATE_MISSING, DELETE_MISSING, the existing code > ERRCODE_NO_DATA_FOUND seems to be an exact match. The LOG message > appears when we don't find the row to be updated or deleted while > applying changes. This can happen if someone deletes the required rows > on the subscriber. This case is similar to unique_key_violation where > we report ERRCODE_UNIQUE_VIOLATION when, during apply, we found the > row with the same key exists (for example, cases like INSERT_EXISTS or > UPDATE_EXISTS). So, I can't think of a reason to use a different > error_code for these cases.
Well, ERRCODE_NO_DATA_FOUND is "Class P0 - PL/pgSQL Error," and it normally occurs when STRICT was used to say that SELECT INTO should return exactly one row. This is a completely different part of the system and a completely different situation. I see that one use of ERRCODE_NO_DATA_FOUND has also found its way into tablecmds.c, but that is probably also a mistake that should be fixed. > Now, the error_code proposed for the other two cases > UPDATE_ORIGIN_DIFFERS, DELETE_ORIGIN_DIFFERS is debatable. The > situation in these cases is that the row exists but differs from the > expected state (already changed by a different origin). As of now, for > these cases, we LOG the message and update the existing rows. I > thought of using ERRCODE_TRIGGERED_DATA_CHANGE_VIOLATION because we > are using it for the case where the tuple to be updated is already > updated/deleted, which is also the case here, but the reason for the > 'already update/delete' is different. So, this is not a perfect match, > but it is worth considering. This error is currently used for situations involving triggers, which may be why it has TRIGGERED in the name. This situation is different. > The other code worth considering is > ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE for UPDATE_ORIGIN_DIFFERS and > DELETE_ORIGIN_DIFFERS cases. We use this error code when we try to > perform some operation, but the required object (say a tuple) is not > in the expected state. Currently, we use it for tuples in the > following cases: The point is that we shouldn't just consider the name of the error code. We should consider more broadly: what is the error code category? How is the error code currently used and is this consistent? People want to be able to filter logs by error code to find the events that they care about, and if you just lump a bunch of quasi-related things under one error code because technically the wording of the error code would fit the situation, then they can't do that. -- Robert Haas EDB: http://www.enterprisedb.com
