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
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 |