Amit Langote <amitlangot...@gmail.com> writes: > On Sun, Dec 22, 2019 at 6:13 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > + * To ensure that it's not leaked completely, re-attach it to the > + * new reldesc, or make it a child of the new reldesc's rd_pdcxt > + * in the unlikely event that there is one already. (See hack in > + * RelationBuildPartitionDesc.)
> While I can imagine that RelationBuildPartitionDesc() might encounter > an old partition descriptor making the re-parenting hack necessary > there, I don't see why it's needed here, because a freshly built > relation descriptor would not contain the partition descriptor after > this patch. Well, as the comment says, that's probably unreachable today. But I could see it happening in the future, particularly if we ever allow partitioned system catalogs. There are a lot of paths through this code that are not obvious to the naked eye, and some of them can cause relcache entries to get populated behind-your-back. Most of relcache.c is careful about this; I do not see an excuse for the partition-data code to be less so, even if we think it can't happen today. (I notice that RelationBuildPartitionKey is making a similar assumption that the partkey couldn't magically appear while it's working, and I don't like it much there either.) >> * It'd be better to declare RelationGetPartitionKey and >> RelationGetPartitionDesc in relcache.h and get their callers out of the >> business of including rel.h, where possible. > Although I agree to declare them in relcache.h, that doesn't reduce > the need to include rel.h in their callers much, because anyplace that > uses RelationGetPartitionDesc() is also very likely to use > RelationGetRelid() which is in rel.h. Hm. Well, we can try anyway. > [1] > https://www.postgresql.org/message-id/CA%2BHiwqFucUh7hYkfZ6x1MVcs_R24eUfNVuRwdE_FwuwK8XpSZg%40mail.gmail.com Oh, interesting --- I hadn't been paying much attention to that thread. I'll compare your PoC there to what I did. regards, tom lane
