On 14 June 2018 at 04:10, Tom Lane <t...@sss.pgh.pa.us> wrote: > There's still one thing I'm a bit confused about here. I noticed that > we weren't actually using the partopfamily and partopcintype fields in > PartitionPruneContext, so I removed them. But that still leaves both > partsupfunc and partcollation as pointers into the relcache that were > subject to this hazard. My testing agrees with lousyjack's results > that both of those were, in fact, being improperly accessed. The OID > comparison effect I mentioned upthread explains why the buildfarm's > cache-clobbering members failed to notice any problem with garbage > partsupfunc data ... but why did we not see any complaints about invalid > collation OIDs? Tis strange.
FWIW It's not working for me before e23bae82cf3 with CLOBBER_FREED_MEMORY, CLOBBER_CACHE_ALWAYS and RELCACHE_FORCE_RELEASE, and: create table listp (a text) partition by list(a); create table listp1 partition of listp for values in ('1'); select * from listp where a = (select '1'); I get: ERROR: cache lookup failed for collation 2139062143 -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services