On 2019/04/14 0:53, Tom Lane wrote: > Amit Langote <amitlangot...@gmail.com> writes: >> On Sat, Apr 13, 2019 at 4:47 AM Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I concluded that that's not parenthetical but pretty relevant... > >> Hmm, do you mean we should grow the same "keep_" logic for >> rd_partcheck as we have for rd_partkey and rd_partdesc? I don't see >> it in the updated patch though. > > No, the "keep_" stuff is only necessary when we're trying to preserve > data structures in-place, which is only important if non-relcache > code might be using pointers to it. Since rd_partcheck is never > directly accessed by external code, only copied, there can't be any > live pointers to it to worry about. Besides which, since it's load > on demand rather than something that RelationBuildDesc forces to be > valid immediately, any comparison would be guaranteed to fail: the > field in the new reldesc will always be empty at this point.
Ah, that's right. It was just that you were replying to this: Robert wrote: > 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. Maybe I just got confused. > Perhaps there's an argument that it should be load-immediately not > load-on-demand, but that would be an optimization not a bug fix, > and I'm skeptical that it'd be an improvement anyway. Makes sense. > Probably this is something to revisit whenever somebody gets around to > addressing the whole copy-vs-dont-copy-vs-use-a-refcount business that > we were handwaving about upthread. OK. >>> I also cleaned up the problem the code had with failing to distinguish >>> "partcheck list is NIL" from "partcheck list hasn't been computed yet". >>> For a relation with no such constraints, generate_partition_qual would do >>> the full pushups every time. > >> Actually, callers must have checked that the table is a partition >> (relispartition). > > That does not mean that it's guaranteed to have any partcheck constraints; > there are counterexamples in the regression tests. It looks like the main > case is a LIST-partitioned table that has only a default partition. Ah, yes. Actually, even a RANGE default partition that's the only partition of its parent has NIL partition constraint. Thanks, Amit
