Andrew Dunstan <andrew.duns...@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
