Re: Support EXCEPT for TABLES IN SCHEMA publications
shveta malik <shveta.malik@gmail.com>
From: shveta malik <shveta.malik@gmail.com>
To: Nisha Moond <nisha.moond412@gmail.com>
Cc: Peter Smith <smithpb2250@gmail.com>,
Zsolt Parragi <zsolt.parragi@percona.com>, pgsql-hackers@lists.postgresql.org, Amit Kapila <amit.kapila16@gmail.com>, shveta malik <shveta.malik@gmail.com>
Date: 2026-07-08T09:28:15Z
Lists: pgsql-hackers
On Wed, Jul 8, 2026 at 2:22 PM shveta malik <shveta.malik@gmail.com> wrote: > > Nisha, the patch (testing wise) is okay, but some code-optimization > might help. I am stuck on reveiw of GetTopMostAncestorInPublication() > and all its callers. > > 1) > caller 1: pub_rf_contains_invalid_column(): > > It is not understood why pub_rf_contains_invalid_column() does not > pass 'exceptPubids' to GetTopMostAncestorInPublication(). Perhaps a > comment will help. IIUC, a parittion (for which we are trying to > verify row-filter expression) can not co-exist in a subscription where > its ROOT is already excluded. This assumption will be true once you > address the issue of CREATE SUB (in [1]) sent in my previous email. > After that, this will still need a comment. > > 2) > Both caller 2 (get_rel_sync_entry) and caller 3 > (is_table_publishable_in_publication) are trying to see if partition > should be considered as included in publication and thus are trying to > see if ROOT is excluded. But the implementation is very different. > > The get_rel_sync_entry() does that by passing except_pubids to > GetTopMostAncestorInPublication(). This except_pubids was computed for > topmost ROOT of the parition in the caller and then it skips checking > pg_pub_namepspace if given pubid is part of except_pubids arguement. > > While is_table_publishable_in_publication() does that by selecting > topmost ancestor incuded in a given pubid using > GetTopMostAncestorInPublication(), without consulting/computing > except_pubids. And then later checks if the ancestor returned by > GetTopMostAncestorInPublication() is in pg_publicaiton_rel with > 'prexcept' true. > > IMO, GetTopMostAncestorInPublication() should itself be inclusive of > logic where it filters out the table (does not return it as result) if > ROOT is excluded. And even we should not be passing an argument for > that (this is my initial thought). By making such a logic, we need not > to bother about all > the callers to see if caller has correct logic to deal with output of > GetTopMostAncestorInPublication(). Can you think on this line and > check the feasibility. > I thought more on this. Do you think we can do this? GetTopMostAncestorInPublication() is already accepting a list of ancestors in a ordered fashion, root at the end. We get root from this ancestor list, check if root is in pg_publication_rel with except=true. If so, we skip the rest of the logic and return InvalidOid from GetTopMostAncestorInPublication(). The 'except_pubids' argument is not required. Callers need not to have special logic to send this arguement or to have extra-processing on output as done by is_table_publishable_in_publication() currently. Let me know if I have missed anything. thanks Shveta
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: Clarify that publication exclusions track table identity.
- 77b6dd909252 19 (unreleased) cited