On 14 June 2018 at 04:10, Tom Lane <tgl@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
