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