Re: Proposal: Conflict log history table for Logical Replication
| От | Dilip Kumar |
|---|---|
| Тема | Re: Proposal: Conflict log history table for Logical Replication |
| Дата | |
| Msg-id | CAFiTN-vc5QpCsG2TyG5AC2gKQwrqKOghGggYAx8ujj2tft-HqA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposal: Conflict log history table for Logical Replication (Dilip Kumar <dilipbalaut@gmail.com>) |
| Ответы |
Re: Proposal: Conflict log history table for Logical Replication
|
| Список | pgsql-hackers |
On Tue, Nov 25, 2025 at 1:59 PM Dilip Kumar <dilipbalaut@gmail.com> 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? -- Regards, Dilip Kumar Google
В списке pgsql-hackers по дате отправления: