Re: Proposal: Conflict log history table for Logical Replication

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.

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:

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..>.

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:

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.

6)
In create_subscription.sgml where we talk about conflict log table,
shall we also point to its structure mentioned in the Conflict page?

thanks
Shveta