Re: Proposal: Conflict log history table for Logical Replication - Mailing list pgsql-hackers

From shveta malik
Subject Re: Proposal: Conflict log history table for Logical Replication
Date
Msg-id CAJpy0uDD6UHvPXbjKjFfgPsEn2DywbekL0Cz+ZE2uLdsgArwEg@mail.gmail.com
Whole thread
In response to Re: Proposal: Conflict log history table for Logical Replication  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Tue, Apr 28, 2026 at 9:45 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 6. Commit message states:
> "If the user chooses to enable logging to a table (by selecting
> 'table' or 'all'),
> an internal logging table named conflict_log_table_<subid> is automatically
> created .."
>
> I see that the patch creates a table with the name
> pg_conflict_<subid>. Apart from updating the commit message, how about
> naming the table as pg_conflict_log_<subid> or pg_subconflict_<subid>.
> In the first alternative pg_conflict_log_<subid>, the table name in
> isolation without schema name describes its purpose, the second
> alternative breaks the repetitiveness of pg_conflict when used with
> schema like pg_conflict.pg_conflict_16394.
>

+1 for pg_conflict.pg_conflict_log_<subid>. It feels more intuitive,
and it leaves room for other tables with the pg_conflict_* prefix in
the pg_conflict schema if needed in the future.

thanks
Shveta



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication
Next
From: Michael Paquier
Date:
Subject: Re: Define DatumGetInt8 function.