public inbox for [email protected]  

help / color / mirror / Atom feed
From: Chao Li <[email protected]>
To: shveta malik <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Euler Taveira <[email protected]>
Cc: GRANT ZHOU <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Dilip Kumar <[email protected]>
Cc: Postgres hackers <[email protected]>
Subject: Re: Improve logical replication usability when tables lack primary keys
Date: Tue, 14 Apr 2026 14:19:46 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJpy0uDiKfNfXc1iYigb3DKKjrE6LNzQZzdXhN+BZKeevLq7DA@mail.gmail.com>
References: <CAEoWx2mMorbMwjKbT4YCsjDyL3r9Mp+z0bbK57VZ+OkJTgJQVQ@mail.gmail.com>
	<CAA4eK1+UL6wVDNzkpHjA7RVLD_8AkrP2tu+RvQ2h5AUjyEe+-Q@mail.gmail.com>
	<[email protected]>
	<CAFiTN-ucvk8JOiLvjii6VXar6nYJvCQDgzp8_4v55yweUmzdzw@mail.gmail.com>
	<[email protected]>
	<CAA4eK1KzjxO-qWjWSox6e6AWH4FVU5ZPEgeZ+na=eyov7umutg@mail.gmail.com>
	<[email protected]>
	<TY4PR01MB16907E1C68EA6EBADCE54ABBE94ABA@TY4PR01MB16907.jpnprd01.prod.outlook.com>
	<[email protected]>
	<CA+FXcm-YZXJpc6E7XEDTv9Yaic=U7Dwnjj4znxJ4gCxUZMcXww@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CAJpy0uAHiwssGCgE54zHgDPPhV4h+O5aeM03D-go8EjY1dNPCg@mail.gmail.com>
	<[email protected]>
	<CAJpy0uD7trdR4bMK1Xxj=mTbiJNty1mMeMprojz-fN1SH_kGAQ@mail.gmail.com>
	<CAJpy0uDiKfNfXc1iYigb3DKKjrE6LNzQZzdXhN+BZKeevLq7DA@mail.gmail.com>



> On Apr 14, 2026, at 13:49, shveta malik <[email protected]> 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/









view thread (26+ messages)

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Improve logical replication usability when tables lack primary keys
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox