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

On Mon, Jan 5, 2026 at 12:11 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Thu, Jan 1, 2026 at 4:01 PM shveta malik <shveta.malik@gmail.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