Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZJjOn-0007Vv-Ml for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Jul 2015 14:29:01 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZJjOm-0004r1-N0 for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Jul 2015 14:29:00 +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.84) (envelope-from ) id 1ZJjOm-0004qo-1X for pgsql-hackers@postgresql.org; Mon, 27 Jul 2015 14:29:00 +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.84) (envelope-from ) id 1ZJjOj-0002a1-4M for pgsql-hackers@postgresql.org; Mon, 27 Jul 2015 14:28:59 +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 t6RESlc2025499; Mon, 27 Jul 2015 10:28:47 -0400 From: Tom Lane To: Andreas Seltenreich cc: pgsql-hackers@postgresql.org Subject: Re: Failing assertions in indxpath.c, placeholder.c and brin_minmax.c In-reply-to: <87k2tm2l3i.fsf@ex.ansel.ydns.eu> References: <871tfv3wor.fsf@ex.ansel.ydns.eu> <15030.1437947313@sss.pgh.pa.us> <87k2tm2l3i.fsf@ex.ansel.ydns.eu> Comments: In-reply-to Andreas Seltenreich message dated "Mon, 27 Jul 2015 08:03:29 +0200" Date: Mon, 27 Jul 2015 10:28:47 -0400 Message-ID: <25498.1438007327@sss.pgh.pa.us> X-Pg-Spam-Score: -3.2 (---) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Andreas Seltenreich writes: > Tom Lane writes: >> I've fixed the first two of these --- thanks for the report! > I let sqlsmith run during the night, and it did no longer trigger the > first two. During roughly a million random queries it triggered the > already mentioned brin one 10 times, but there was also one instance of > this new one in the log: Oh goody, more fun. I'll take a look. >> I'm a bit confused about this aspect of your report though, because in >> my hands that example fails clear back to 9.2. It doesn't seem to require >> the predtest.c improvement to expose the fault. > Hmm, I actually used a different, uglier query to trigger this assertion > for the bisection run. Ah, okay. The triggering condition for both those cases is provably-contradictory restriction clauses on an inheritance relation. In what you showed yesterday, that was something like "x < x AND x IS NULL", which the planner has been able to recognize as contradictory for a long time because "<" is strict. (It did not, and still doesn't, notice that "x < x" all by itself is contradictory...). But here it looks like the trigger is from public.b as rel4551420 where ( rel4551420.bb>rel4551420.bb ) and ( rel4551420.bb bb. So that's why this run started to fail there, even though the bug it was tickling is much older. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers