On Tuesday, December 16, 2025 2:47 PM Chao Li <li.evan.chao@gmail.com> wrote:
> > On Dec 15, 2025, at 13:48, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > So, without patch, there is no way we can silently replicate the
> > UPDATE/DELETE. Ideally, users should alter the tables and make RI as
> > FULL in such cases if they don't have PK for such tables. Falling back
> > to FULL for DEFAULT when the table doesn't have PK based on GUC has a
> > downside that it will increase WAL volume by a large amount.
>
> I agree that this downside exists, but it is an inherent cost that users must
> accept if they choose to replicate all tables, including those without a primary
> key. In practice, users who opt into such a configuration are typically aware of
> the WAL overhead and make that trade-off consciously.
>
> > I think it should be done specific to tables that users want to replicate.
>
> That is why I mentioned earlier that the new GUC should only be configurable
> at the database level (via ALTER DATABASE). However, I agree that there is
> still a risk that a user could mistakenly set it in postgresql.conf, thereby
> making it effective for the entire cluster.
>
> > I don't know what is a good way to give to users who don't want to do
> > the required setup but if we really want to provide something, it is
> > better to allow such a thing via the publication option instead.
>
> Using a publication-level option could also work. One complication, however,
> is that a table can belong to multiple publications. For example, if table_a
> belongs to both pub_a and pub_b, and only pub_a is configured with
> fallback_to_full while pub_b keeps the default behavior (fallback_to_none),
> then the effective behavior for table_a would need to remain
> fallback_to_none, meaning that UPDATE/DELETE would still not be allowed if
> table_a has not a primary key.
I think the common approach for combining options between publications is to
use an "OR" logic. For example, if at least one publication's option is true, we
treat the option as true for a given table. This pattern is evident in
CheckCmdReplicaIdentity(), where we conduct replica identity checks if any
publication replicates INSERTs/UPDATEs for the table even if some other publications
do not replicate.
And I also prefer using a publication option as it's always beneficial to
minimize unnecessary WAL generation whenever possible.
Best Regards,
Hou zj
