On Tue, Nov 25, 2025 at 4:06 PM Dilip Kumar <[email protected]> wrote: > > On Tue, Nov 25, 2025 at 1:59 PM Dilip Kumar <[email protected]> wrote: > > > > On a separate note, I've been considering how to manage conflict log > insertions when an error causes the outer transaction to abort, which > seems to be a non-trivial. > > Here is what I have in mind: > ====================== > First, prepare_conflict_log() would be executed from > ReportApplyConflict(). This function would handle all preliminary > work, such as preparing the tuple for the conflict log table. Second, > insert_conflict_log() would be executed. If the error level in > ReportApplyConflict() is LOG, the insertion would occur directly. > Otherwise, the log information would be stored in a global variable > and inserted in a separate transaction once we exit start_apply() due > to the error. > > @shveta malik @Amit Kapila let me know what you think? Or do you > think it can be simplified?
While digging more into this I am wondering why CT_MULTIPLE_UNIQUE_CONFLICTS is reported as an error and all other conflicts as LOG? -- Regards, Dilip Kumar Google
