On Fri, Feb 27, 2026 at 5:01 PM Nisha Moond <[email protected]> wrote:
>
> Thanks for the patches, I am still testing the patches, but sharing a
> few initial review comments.
>
I did few tests on v51 all patches, please find further comments -
1. Partition Related Behavior
-----------------------------
Setup:
CREATE TABLE t_part (id int) PARTITION BY RANGE (id);
CREATE TABLE t_part_p1 PARTITION OF t_part FOR VALUES FROM (0) TO (100);
CREATE TABLE t_part_p2 (id int);
ALTER TABLE t_part ATTACH PARTITION t_part_p2 FOR VALUES FROM (100) TO (200);
t_part
|_> t_part_p1
|_> t_part_p2
Publication:
create publication pubp1 for ALL TABLES EXCEPT TABLE (t_part);
-- No data from all three tables is replicated, which is expected.
1a) DETACH t_part_p2 from parent
ALTER TABLE t_part DETACH PARTITION t_part_p2;
When t_part_p2 is detached, it becomes a standalone table and is no
longer part of the EXCEPT hierarchy. But, replication does not start
automatically. It requires REFRESH PUBLICATION on the subscriber.
Should we add a warning/hint during DETACH command to inform users
that REFRESH PUBLICATION is required?
It may also help to update the related documentation.
~~
1b): Attach the partition again
ALTER TABLE t_part ATTACH PARTITION t_part_p2 FOR VALUES FROM (100) TO (200);
When the partition is attached back, replication stops immediately as
it becomes part of the excluded parent again. No REFRESH PUBLICATION
is required on the subscriber. In this case, users may not realize
that replication has stopped. Should we consider adding a warning
during ATTACH in such scenarios?
~~~~
2. Inherited Tables Behavior
Setup:
CREATE TABLE t_inh (id int);
CREATE TABLE t_inh_c1 (c1 int) INHERITS (t_inh);
CREATE TABLE t_inh_c2 (c2 int) INHERITS (t_inh);
t_inh
|_> t_inh_c1
|_> t_inh_c2
Publication:
create publication pubi1 for ALL TABLES EXCEPT TABLE (t_inh);
--All three tables are not replicated.
2a): Remove child from parent
alter table t_inh_c1 NO INHERIT t_inh;
\d+ t_inh shows:
Except Publications:
"pubi1"
Child tables: t_inh_c2
But the publication still shows:
Except tables:
"public.t_inh"
"public.t_inh_c1"
"public.t_inh_c2"
t_inh_c1 is no longer part of the excluded hierarchy, yet it remains
in the EXCEPT list and replication does not start for it.
This appears inconsistent and may be a bug.
2b): Add inheritance to excluded parent
alter table t_inh_c1 inherit t_inh;
Publication:
Except tables:
"public.t_inh"
"public.t_inh_c2"
\d+ t_inh shows:
Except Publications:
"pubi1"
Child tables: t_inh_c1,
t_inh_c2
Here, the table hierarchy is updated, but the publication EXCEPT list
is not updated. Replication continues for t_inh_c1 even though its
parent is excluded.
>From a user perspective, this appears incorrect.
I am not sure whether we can determine if the publication was created
for ONLY parent or for parent including children once it is created.
If this behavior is unavoidable, it should be documented.
~~~~
3. SET EXCEPT TABLE Behavior
Publication created with:
create publication pubi5 for ALL TABLES EXCEPT TABLE (ONLY t_inh);
-- Replicates t_inh_c1 and t_inh_c2, as expected.
Now:
alter publication pubi5 SET EXCEPT TABLE t_inh;
Publication pubi5
Except tables:
"public.t_inh"
"public.t_inh_c1"
"public.t_inh_c2"
But, replication continues on the subscriber for both t_inh_c1 and
t_inh_c2 even after REFRESH PUBLICATION. This seems like a bug.
Note: The opposite works correctly. If SET EXCEPT removes previous
tables, replication starts/resumes immediately for these tables.
~~~~
--
Thanks,
Nisha
