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

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>


--
Regards,
Dilip Kumar
Google