On 12 June 2018 at 10:24, Tom Lane <t...@sss.pgh.pa.us> wrote: > After looking closer, that code isn't just inefficient, it's flat > out broken. The reason is that ExecSetupPartitionPruneState thinks > it can store some pointers into the target relation's relcache entry > in the PartitionPruneContext, and then continue to use those pointers > after closing the relcache entry. Nope, you can't do that.
I think the best fix is to just have a separate FmgrInfo for each step and partkey comparison. Some FmgrInfos will end up identical, but that's probably a small price to pay. Perhaps they should be separate anyway so that the fn_extra is not shared between different quals comparing to the same partition key? I went with an array of FmgrInfos rather than an array of pointers to FmgrInfos for cache efficiency. This does require that InvalidOid is 0, since I've palloc0'd that memory, and I'm checking if the cache is yet to be populated with: if (!OidIsValid(context->stepcmpfuncs[stateidx].fn_oid)) Patch attached. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
fix_bogus_fmgrinfo_initialisation.patch
Description: Binary data
