Re: Proposal: Conflict log history table for Logical Replication

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