On Wed, Nov 26, 2025 at 2:05 PM shveta malik <[email protected]> wrote: > > 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? > > > > I could not think of a better way. This idea works for me. I had > doubts if it will be okay to start a new transaction in catch-block > (if we plan to do it in start_apply's), but then I found few other > functions doing it (see do_autovacuum, perform_work_item, > _SPI_commit). So IMO, we should be good. >
On re-reading, I think you were not suggesting to handle it in the CATCH block. Where exactly once we exit start_apply? But since the situation will arise only in case of ERROR, I thought handling in catch-block could be one option. thanks Shveta
