On Thu, Aug 13, 2026 at 11:10 AM shveta malik <[email protected]> wrote: > > On Wed, Aug 12, 2026 at 9:13 PM Dilip Kumar <[email protected]> wrote: > > > > > > Changed. > > > > Thanks Dilip. A few trivial comments on v69: > > 1) > +insert_conflict_log_tuple(Relation conflictlogrel, HeapTuple tuple) > +{ > + Assert(tuple != NULL); > + > + heap_insert(conflictlogrel, tuple, > + GetCurrentCommandId(true), 0, NULL); > +} > > Should we get rid of this function now? > a) It does not do anything extra other than heap_insert() > b) There is only one caller.
So I have merged prepare_conflict_log_tuple() code into the insert_conflict_log_tuple() and kept the name as insert_conflict_log_tuple() > 2) > LOG: conflict detected on relation "public.tab1": conflict=delete_missing > DETAIL: Conflict details are logged to the conflict log table: > pg_conflict_log_16390 > > It will be good to specify schema qualified name here: > pg_conflict.pg_conflict_log_16390, as we do at other places. Done > > 3) > The doc page shows: > > 29.8.1. Conflict logging > 29.8.2. Table-based logging > 29.8.3. File-based logging > 29.8.4. Notes > > Should it be: > 29.8.1. Conflict logging > 29.8.1.1. Table-based logging > 29.8.1.2. File-based logging > 29.8.2. Notes > > What do you say? Yeah I have moved 29.8.1.1, Table-based logging and 29.8.1.2, File-based logging section into the 29.8.1. Conflict logging section, but from the main page I have only kept the link unabled for the 29.8.1. Conflict logging this is same as how it is done for other subsections, e.g. 29.14.3.1 etc.. -- Regards, Dilip Kumar Google
v70-0001-Implement-the-conflict-insertion-infrastructure-.patch
Description: Binary data
