On Wed, Mar 13, 2019 at 3:14 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Yeah, but usually there's some comment pointing it out. I also wonder > if there aren't corner-case bugs; it seems a bit bogus for example that > rd_pdcxt is created without any thought as to whether it might be set > already. It's not clear whether this has been written with the > level of paranoia that's appropriate for messing with a relcache entry, > and some comments would make it a lot clearer (a) if that is true and > (b) what assumptions are implicitly being shared with relcache.c.
Yeah, this is all pretty new code, and it probably has some bugs we haven't found yet. > Meanwhile, who's going to take point on cleaning up rd_partcheck? > I don't really understand this code well enough to know whether that > can share one of the existing partitioning-related sub-contexts. Well, it would be nice if Amit Langote worked on it since he wrote the original version of most of this code, but I'm sure he'll defer to you if you feel the urge to work on it, or I can take a look at it (not today). To your question, I think it probably can't share a context. Briefly, rd_partkey can't change ever, except that when a partitioned relation is in the process of being created it is briefly NULL; once it obtains a value, that value cannot be changed. If you want to range-partition a list-partitioned table or something like that, you have to drop the table and create a new one. I think that's a perfectly acceptable permanent limitation and I have no urge whatever to change it. rd_partdesc changes when you attach or detach a child partition. rd_partcheck is the reverse: it changes when you attach or detach this partition to or from a parent. It's probably helpful to think of the case of a table with partitions each of which is itself partitioned -- the table at that middle level has to worry both about gaining or losing children and about being ripped away from its parent. As a parenthetical note, I observe that relcache.c seems to know almost nothing about rd_partcheck. rd_partkey and rd_partdesc both have handling in RelationClearRelation(), but rd_partcheck does not, and I suspect that's wrong. So the problems are probably not confined to the relcache-drop-time problem that you observed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company