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
