Re: why partition pruning doesn't work?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: why partition pruning doesn't work?
Date: 2018-06-11 23:05:04
Message-ID: 27543.1528758304@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-06-11 23:16:34 Re: [COMMITTERS] pgsql: Logical replication
Previous Message Nico Williams 2018-06-11 23:00:27 Re: [PATCH v18] GSSAPI encryption support