Re: why partition pruning doesn't work? - Mailing list pgsql-hackers

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 06/11/2018 06:24 PM, Tom Lane wrote:
>> If we had any buildfarm critters running valgrind on
>> RELCACHE_FORCE_RELEASE or CLOBBER_CACHE_ALWAYS builds, they'd have
>> detected use of uninitialized memory here ... but I don't think we have
>> any.  (The combination of valgrind and CCA would probably be too slow to
>> be practical :-(, though maybe somebody with a fast machine could do
>> the other thing.)

> I don't have a fast machine, but I do have a slow machine already
> running valgrind and not doing much else :-) Let's see how lousyjack
> does with -DRELCACHE_FORCE_RELEASE

I just tried the case here, and it doesn't even get as far as any
of the partitioning tests: it bombs out in inherit.sql :-(

==00:00:06:55.816 26107== Invalid read of size 4
==00:00:06:55.816 26107==    at 0x5F3978: ATExecDropInherit (tablecmds.c:11928)
==00:00:06:55.816 26107==    by 0x60212A: ATExecCmd (tablecmds.c:4241)
==00:00:06:55.816 26107==    by 0x602CC4: ATController (tablecmds.c:3976)
==00:00:06:55.816 26107==    by 0x7910EA: ProcessUtilitySlow (utility.c:1117)
==00:00:06:55.816 26107==    by 0x79180F: standard_ProcessUtility (utility.c:920)
==00:00:06:55.816 26107==    by 0x78D748: PortalRunUtility (pquery.c:1178)
==00:00:06:55.816 26107==    by 0x78E6D0: PortalRunMulti (pquery.c:1331)
==00:00:06:55.816 26107==    by 0x78EF8F: PortalRun (pquery.c:799)
==00:00:06:55.816 26107==    by 0x78B35C: exec_simple_query (postgres.c:1122)
==00:00:06:55.816 26107==    by 0x78C8B3: PostgresMain (postgres.c:4153)
==00:00:06:55.816 26107==    by 0x70FBD5: PostmasterMain (postmaster.c:4361)
==00:00:06:55.816 26107==    by 0x67AE4F: main (main.c:228)
==00:00:06:55.816 26107==  Address 0xe823e90 is 179,504 bytes inside a recently re-allocated block of size 524,288
alloc'd
==00:00:06:55.816 26107==    at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
==00:00:06:55.816 26107==    by 0x8BBB35: AllocSetAlloc (aset.c:923)
==00:00:06:55.816 26107==    by 0x8C4473: palloc (mcxt.c:938)
==00:00:06:55.816 26107==    by 0x488DEF: CreateTemplateTupleDesc (tupdesc.c:66)
==00:00:06:55.816 26107==    by 0x88D2C0: RelationBuildDesc (relcache.c:416)
==00:00:06:55.816 26107==    by 0x8904B5: RelationIdGetRelation (relcache.c:1943)
==00:00:06:55.816 26107==    by 0x4C93BF: relation_open (heapam.c:1135)
==00:00:06:55.816 26107==    by 0x4D8305: index_open (indexam.c:154)
==00:00:06:55.816 26107==    by 0x62D6EB: ExecOpenIndices (execIndexing.c:197)
==00:00:06:55.816 26107==    by 0x53B607: CatalogOpenIndexes (indexing.c:49)
==00:00:06:55.816 26107==    by 0x556467: recordMultipleDependencies (pg_depend.c:112)
==00:00:06:55.816 26107==    by 0x560D44: create_toast_table (toasting.c:385)


That one's pretty obvious when you look at the code:

    /* keep our lock on the parent relation until commit */
    heap_close(parent_rel, NoLock);

    ObjectAddressSet(address, RelationRelationId,
                     RelationGetRelid(parent_rel));

It looks like this might be a fruitful source of creepie-crawlies.

            regards, tom lane