| From: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
|---|---|
| To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
| Cc: | vignesh C <vignesh21(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, shveta malik <shveta(dot)malik(at)gmail(dot)com> |
| Subject: | Re: Support EXCEPT for TABLES IN SCHEMA publications |
| Date: | 2026-08-14 05:58:50 |
| Message-ID: | CAJpy0uAg-pMq37fBd7SAyGVwCCPyG1pGQAOEDkMU7kJuLUN3KQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 13, 2026 at 12:52 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
>
> 2b.
> /In the partition case/For partitions/
>
> AFAICT this case is referring to something like: "FOR TABLE part,
> TABLES IN SCHEMA EXCEPT (part_root)"
>
> But, isn't that just a variation of the 1st case issue? e.g. where
> table "part" is not yet visible for later lookup of "root", then you
> wont be able to check integrity of the partition tree regardless of
> the up/down traversal logic, so I wasn't sure why this 2nd case was
> separately mentioned at all.
The second point is different from the first. Consider this case:
CREATE PUBLICATION pub1 FOR s2.tab_part;
ALTER PUBLICATION pub1 ADD TABLES IN SCHEMA s2 EXCEPT (TABLE tab_root);
Here, the partition entry in pg_publication_rel is visible to the
second command in publication_add_relation() and in
check_publication_add_relation(). But the checks there are not
sufficient to identify the error. If we try to detect the error while
adding tab_root in publication_add_relation(),
we would need to perform a full descendant search to determine whether
any of its descendants are already present in pg_publication_rel. This
downward traversal is what we are trying to avoid in
publication_add_relation(). Geenrally we rely on ancestor-lookup and
we want to stick to that instead of introducing a new logic.
Thus the logic in CheckExceptNotInTableList() is needed here. It reads
all explicitly added entries from pg_publication_rel, looks up their
ancestors to find the root, and checks the EXCEPT entries against that
root.
This is my understanding, let's wait for Nisha's comments as well.
I feel the comment about the second case should be moved to patch002,
where it actually makes sense and explains why it is needed even after
point 1.
thanks
Shveta
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-08-14 06:16:24 | Re: Allow a condition string in an injection point |
| Previous Message | Bertrand Drouvot | 2026-08-14 05:47:06 | Re: pg_control_checkpoint(): add "data_checksum_version" (Pg19)? |