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

Attachment: v70-0001-Implement-the-conflict-insertion-infrastructure-.patch
Description: Binary data

Reply via email to