> On Apr 14, 2026, at 13:49, shveta malik <shveta.malik@gmail.com> wrote:
>
> On thinking more about the initial design with a GUC-based approach, I
> believe we already have a similar precedent where both a GUC and a
> table/column-level property coexist. For example, the
> default_toast_compression GUC allows setting a default compression
> method globally, while users can still override it at the column level
> during CREATE TABLE or ALTER TABLE. A similar approach could work in
> our case as well.
Thanks for pointing out this.
Yes, one of solutions I initially considered was to introduce a GUC, say default_replica_identity_fallback, with a
defaultvalue of “NONE”, which is the current behavior. We just need to support one more value “FULL”, then when a table
hasno primary key, its replica identity falls back to FULL. Users may freely set the table's replica identity to any
value.And the database administrator can set the GUC at either cluster level or database level based on their operation
practices.
>
> Regarding the publication-level property, apart from the potential
> data-integrity issues discussed earlier, I also have another concern.
> If we introduce a publication-level fallback, we would effectively be
> deciding what gets logged in WAL for a particular table (i.e., whether
> to log REPLICA IDENTITY FULL) based on a publication parameter. This
> does not seem quite right to me. Shouldn't WAL logging typically be
> independent of publication configuration? Or do we already have a case
> where WAL logging behavior depends on publication-level properties?
>
> Thanks,
> Shveta
For this, I really want to hear back from Amit.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
