Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fSVsG-0005Jw-EI for pgsql-hackers@arkaria.postgresql.org; Mon, 11 Jun 2018 23:05:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fSVsF-0006wl-8z for pgsql-hackers@arkaria.postgresql.org; Mon, 11 Jun 2018 23:05:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fSVsF-0006wZ-1m for pgsql-hackers@lists.postgresql.org; Mon, 11 Jun 2018 23:05:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fSVsB-0000Kx-KZ for pgsql-hackers@lists.postgresql.org; Mon, 11 Jun 2018 23:05:18 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w5BN54Bq027544; Mon, 11 Jun 2018 19:05:04 -0400 From: Tom Lane To: Andrew Dunstan cc: David Rowley , Amit Langote , Dmitry Dolgov <9erthalion6@gmail.com>, Jeff Janes , Ashutosh Bapat , Pavel Stehule , PostgreSQL Hackers Subject: Re: why partition pruning doesn't work? In-reply-to: References: <10432.1528045900@sss.pgh.pa.us> <569483c5-a273-6537-1b5d-7a271ce439fb@lab.ntt.co.jp> <22805.1528386192@sss.pgh.pa.us> <21787.1528428171@sss.pgh.pa.us> <6366.1528571895@sss.pgh.pa.us> <12624.1528578026@sss.pgh.pa.us> <26279.1528670981@sss.pgh.pa.us> <17850.1528755844@sss.pgh.pa.us> Comments: In-reply-to Andrew Dunstan message dated "Mon, 11 Jun 2018 18:41:20 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27542.1528758304.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jun 2018 19:05:04 -0400 Message-ID: <27543.1528758304@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andrew Dunstan 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 t= o >> 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 :-( =3D=3D00:00:06:55.816 26107=3D=3D Invalid read of size 4 =3D=3D00:00:06:55.816 26107=3D=3D at 0x5F3978: ATExecDropInherit (table= cmds.c:11928) =3D=3D00:00:06:55.816 26107=3D=3D by 0x60212A: ATExecCmd (tablecmds.c:4= 241) =3D=3D00:00:06:55.816 26107=3D=3D by 0x602CC4: ATController (tablecmds.= c:3976) =3D=3D00:00:06:55.816 26107=3D=3D by 0x7910EA: ProcessUtilitySlow (util= ity.c:1117) =3D=3D00:00:06:55.816 26107=3D=3D by 0x79180F: standard_ProcessUtility = (utility.c:920) =3D=3D00:00:06:55.816 26107=3D=3D by 0x78D748: PortalRunUtility (pquery= .c:1178) =3D=3D00:00:06:55.816 26107=3D=3D by 0x78E6D0: PortalRunMulti (pquery.c= :1331) =3D=3D00:00:06:55.816 26107=3D=3D by 0x78EF8F: PortalRun (pquery.c:799) =3D=3D00:00:06:55.816 26107=3D=3D by 0x78B35C: exec_simple_query (postg= res.c:1122) =3D=3D00:00:06:55.816 26107=3D=3D by 0x78C8B3: PostgresMain (postgres.c= :4153) =3D=3D00:00:06:55.816 26107=3D=3D by 0x70FBD5: PostmasterMain (postmast= er.c:4361) =3D=3D00:00:06:55.816 26107=3D=3D by 0x67AE4F: main (main.c:228) =3D=3D00:00:06:55.816 26107=3D=3D Address 0xe823e90 is 179,504 bytes insi= de a recently re-allocated block of size 524,288 alloc'd =3D=3D00:00:06:55.816 26107=3D=3D at 0x4A06A2E: malloc (vg_replace_mall= oc.c:270) =3D=3D00:00:06:55.816 26107=3D=3D by 0x8BBB35: AllocSetAlloc (aset.c:92= 3) =3D=3D00:00:06:55.816 26107=3D=3D by 0x8C4473: palloc (mcxt.c:938) =3D=3D00:00:06:55.816 26107=3D=3D by 0x488DEF: CreateTemplateTupleDesc = (tupdesc.c:66) =3D=3D00:00:06:55.816 26107=3D=3D by 0x88D2C0: RelationBuildDesc (relca= che.c:416) =3D=3D00:00:06:55.816 26107=3D=3D by 0x8904B5: RelationIdGetRelation (r= elcache.c:1943) =3D=3D00:00:06:55.816 26107=3D=3D by 0x4C93BF: relation_open (heapam.c:= 1135) =3D=3D00:00:06:55.816 26107=3D=3D by 0x4D8305: index_open (indexam.c:15= 4) =3D=3D00:00:06:55.816 26107=3D=3D by 0x62D6EB: ExecOpenIndices (execInd= exing.c:197) =3D=3D00:00:06:55.816 26107=3D=3D by 0x53B607: CatalogOpenIndexes (inde= xing.c:49) =3D=3D00:00:06:55.816 26107=3D=3D by 0x556467: recordMultipleDependenci= es (pg_depend.c:112) =3D=3D00:00:06:55.816 26107=3D=3D by 0x560D44: create_toast_table (toas= ting.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