public inbox for [email protected]
help / color / mirror / Atom feedFrom: shveta malik <[email protected]>
To: Chao Li <[email protected]>
Cc: Euler Taveira <[email protected]>
Cc: GRANT ZHOU <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: Dilip Kumar <[email protected]>
Cc: Postgres hackers <[email protected]>
Cc: shveta malik <[email protected]>
Subject: Re: Improve logical replication usability when tables lack primary keys
Date: Tue, 14 Apr 2026 11:19:05 +0530
Message-ID: <CAJpy0uDiKfNfXc1iYigb3DKKjrE6LNzQZzdXhN+BZKeevLq7DA@mail.gmail.com> (raw)
In-Reply-To: <CAJpy0uD7trdR4bMK1Xxj=mTbiJNty1mMeMprojz-fN1SH_kGAQ@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>
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.
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
view thread (26+ messages) latest in thread
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: <CAJpy0uDiKfNfXc1iYigb3DKKjrE6LNzQZzdXhN+BZKeevLq7DA@mail.gmail.com>
* 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