Re: Improve logical replication usability when tables lack primary keys

> On Apr 14, 2026, at 13:49, shveta malik <shveta(dot)malik(at)gmail(dot)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 default value of “NONE”, which is the current behavior. We just need to support one more value “FULL”, then when a table has no 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/