Re: Proposal: Conflict log history table for Logical Replication

On Mon, Jan 5, 2026 at 12:11 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Thu, Jan 1, 2026 at 4:01 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > Few comments on v17-003.
> > <The doc does not compile.>
> >
> > logical-replication.sgml
> > 1)
> > + <link linkend="sql-dropsubscription"><command>DROP
> > SUBSCRIPTION</command></link>. When the
> > + <literal>conflict_log_destination</literal> parameter is set to
> > <literal>table</literal>
> > + or <literal>all</literal>, the system automatically manages a
> > dedicated conflict
> > + storage table. This table is dropped automatically when the subscription is
> > + removed via <command>DROP SUBSCRIPTION</command>.
> >
> > + <para>
> > + Conflicts that occur during replication are typically logged as plain text
> > + in the server log, which can be difficult for automated monitoring and
> > + analysis. The <command>CREATE SUBSCRIPTION</command> command provides the
> > + <link linkend="sql-createsubscription-params-with-conflict-log-destination">
> > + <literal>conflict_log_destination</literal></link> option to record detailed
> > + conflict information in a structured, queryable format, significantly
> > + improving post-mortem analysis and operational visibility of the replication
> > + setup by logging to a system-managed table.
> > +
> >
> > Do we really need these at 2 places in the same section? The 2nd
> > paragraph can be tweaked to include the first one and placed at the
> > end of that section. How about:
> >
> > Conflicts that occur during replication are, by default, logged as plain text
> > in the server log, which can make automated monitoring and analysis difficult.
> > The <command>CREATE SUBSCRIPTION</command> command provides the
> > <link linkend="sql-createsubscription-params-with-conflict-log-destination">
> > <literal>conflict_log_destination</literal></link> option to record detailed
> > conflict information in a structured, queryable format. When this parameter
> > is set to <literal>table</literal> or <literal>all</literal>, the system
> > automatically manages a dedicated conflict storage table, which is created
> > and dropped along with the subscription. This significantly improves post-mortem
> > analysis and operational visibility of the replication setup.
>
> Yeah I am fine with doing this.
>
> > 2)
> > + in the following <firstterm>conflict</firstterm> cases. If the subscription
> > + was created with the <literal>conflict_log_destination</literal> set to
> > + <literal>table</literal>, detailed conflict information is also inserted
> > + into an internally managed table named
> >
> > + When the <literal>conflict_log_destination</literal> is set to
> > + <literal>table</literal>, the system automatically creates a new table with
> > + a predefined schema to log conflict details.
> >
> > Should we mention 'all' also in both of above:
>
> Make sense.
>
> > 3)
> > + <literal>pg_conflict.conflict_log_table_<subscription_oid></literal>,
> >
> > I think we can not write <subscription_oid>, it will look for
> > finishing tag </sub..>.
>
> Will fix.
>
> > 4)
> > The log format for logical replication conflicts is as follows:
> >
> > We can even modify this line to something like:
> > If <literal>conflict_log_destination</literal> is left at the default
> > setting or explicitly configured
> > as <literal>log</literal> or <literal>all</literal>, logical
> > replication conflicts are logged in the following format:
>
> +1
>
> > 5)
> > alter_subscription.sgml:
> > +
> > + <para>
> > + When switching <literal>conflict_log_destination</literal> to
> > <literal>table</literal>,
> > + the system will ensure the internal logging table exists. If
> > switching away
> > + from <literal>table</literal>, the logging stops, but the
> > previously recorded
> > + data remains until the subscription is dropped.
> > + </para>
> >
> > I do not think this info is true. We drop the table when we alter
> > conflict_log_destination to set a non-table value.
>
> Will fix this.
>
> > 6)
> > In create_subscription.sgml where we talk about conflict log table,
> > shall we also point to its structure mentioned in the Conflict page?
>
> I do not understand this, do you mean the schema of the conflict log
> table? For that we already have a dedicated section[1]?
>
> <table id="logical-replication-conflict-log-schema">
> <title>Conflict Log Table Schema</title>
> <tgroup cols="3">
> <thead>
> <row>
> <entry>Column</entry>
> <entry>Type</entry>
> <entry>Description</entry>
> </row>
> </thead>

Here is the updated version of patch, Vignesh's patches must be
rebased again on the new version.

--
Regards,
Dilip Kumar
Google