Re: Proposal: Conflict log history table for Logical Replication

A few comments on v50:

1)
+ /*
+ * Conflict log tables are used internally for logical replication
+ * conflict logging and should not have extended statistics, as it
+ * could disrupt conflict logging.
+ */

Suggestion:
/*
* Conflict log tables are system-managed tables used internally for
* logical replication conflict logging. Similar to indexes, user-defined
* extended statistics are not supported on these tables at present.
*/

2)
Assertion hit in alter_sub_conflict_log_dest():

set allow_system_table_mods=on
create subscription sub1 connection '...' publication pub1
WITH(conflict_log_destination='log');
select oid from pg_subscription;

--CREATE clt USING SAME oid
create table pg_conflict.pg_conflict_log_16501(i int);

--change destination to table/all
alter subscription sub1 SET (CONFLICT_LOG_DESTINATION = 'ALL');

--this asserts here:
2026-06-15 11:10:40.540 IST [10626] LOG: background worker "logical
replication tablesync worker" (PID 11397) exited with exit code 1
TRAP: failed Assert("IsBinaryUpgrade"), File: "subscriptioncmds.c",
Line: 1554, PID: 10662

alter_sub_conflict_log_dest(): Assert(IsBinaryUpgrade);

Should we fix Assert or restrict table creation in pg_conflict scehma?
We allow it for toast-schema though when allow_system_table_mods=ON.
But I don't see a use case for allowing this.

3)
I'm not sure whether the comments (at [1]) regarding the TRY-CATCH
block were considered or perhaps overlooked. Please ignore this if you
are already taking them into account.

Doc-patch:
<caught my eye while checking something, not reviewing the doc-patch
rigth now though>

4)
+ direct user manipulation. Unlike <literal>pg_catalog</literal>, the
+ <literal>pg_catalog</literal> schema is not implicitly included in the
+ search path, so objects within it must be referenced explicitly or by
+ adjusting the search path.

Second pg_catalog should be replaced with pg_conflict

5)
+ as the <emphasis>conflict schema</emphasis>) contains system managed

+ The <literal>pg_conflict</literal> schema that contains system-managed

system managed or system-managed, we can use same at both the places.

~~

[1]: https://www.postgresql.org/message-id/CAJpy0uBSY7zTH%3D4TvAOS%3Dkj9vivBUc9NO%2BVp6KNw-Na9RiAsMg%40mail.gmail.com

thanks
Shveta