Few comments on 0003: 1) Section '29.2. Subscription' has this:
~~ 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 CREATE SUBSCRIPTION command provides the conflict_log_destination option to record detailed conflict information in a structured, queryable format. When this parameter is set to table or all, the system automatically manages a dedicated conflict log table, which is created and dropped along with the subscription. This significantly improves post-mortem analysis and operational visibility of the replication setup. ~~ This new section begins by discussing log-destination without providing much background on conflicts, which makes it feel somewhat out of place. It could be made more general by first referring the reader to the 'Conflicts' page. How about this: Conflicts can occur during logical replication when changes from the publisher cannot be applied on the subscriber, for example due to constraint violations or concurrent data modifications. An overview of possible conflict types is provided in Section 29.4, Logical Replication Conflicts. By default, conflict information is written to the server log. The CREATE SUBSCRIPTION command provides the conflict_log_destination parameter, which allows conflict details to be recorded in a dedicated table, making post-mortem analysis and operational monitoring easier. 2) '29.8. Conflicts' section has this: ~~ Note that there are other conflict scenarios, such as exclusion constraint violations. Currently, we do not provide additional details for them in the log. The conflict_log_destination parameter can automatically creates a dedicated conflict log table. This table is created in the dedicated pg_conflict namespace. The name of the conflict log table is pg_conflict_<subid>. The predefined schema of this table is detailed in Table 29.3. ~~ This phrasing feels somewhat abrupt and lacks context. A clearer version could be: By default, conflict information is written to the server log. The CREATE SUBSCRIPTION command also provides the conflict_log_destination parameter to record detailed conflict information in a structured, queryable format. When this parameter is set to table or all, the system automatically manages a dedicated conflict log table, which is created and dropped along with the subscription. The table is created in the pg_conflict schema and is named pg_conflict_<subid>. The schema of this table is described in Table 29.3. 3) 'Restrictions' section has this: Conflict log tables (see conflict_log_destination parameter) are never published, even when using FOR ALL TABLES in a publication. We shall also mention the restriction of publishing 'for tables in schema pg_conflict'. thanks Shveta
