Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hsWAo-0003df-Al for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jul 2019 17:44:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hsWAn-0007jJ-3C for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Jul 2019 17:44:29 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1hsWAm-0007ft-Og for pgsql-hackers@lists.postgresql.org; Tue, 30 Jul 2019 17:44:28 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hsWAg-0007EU-4k for pgsql-hackers@postgresql.org; Tue, 30 Jul 2019 17:44:28 +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 x6UHiHa0027871; Tue, 30 Jul 2019 13:44:17 -0400 From: Tom Lane To: Robert Haas cc: Michael Paquier , Andres Freund , Alvaro Herrera , PostgreSQL Hackers Subject: Re: TopoSort() fix In-reply-to: References: <20190726220538.GA17809@alvherre.pgsql> <20190726234835.xqyfukqhhzdiqoih@alap3.anarazel.de> <17997.1564187056@sss.pgh.pa.us> <20190729015059.GE6959@paquier.xyz> <23797.1564412165@sss.pgh.pa.us> <3243.1564437314@sss.pgh.pa.us> <13215.1564451308@sss.pgh.pa.us> <11847.1564496844@sss.pgh.pa.us> <27546.1564508196@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 30 Jul 2019 13:40:06 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27869.1564508657.1@sss.pgh.pa.us> Date: Tue, 30 Jul 2019 13:44:17 -0400 Message-ID: <27870.1564508657@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > On Tue, Jul 30, 2019 at 1:36 PM Tom Lane wrote: >> In any case, my question at the moment is whether we need the belt-and- >> suspenders-too approach of having both non-parallel-safe marking and an >> explicit check inside these functions. We've largely moved away from >> hard-wired checks for e.g. superuserness, and surely these things are >> less dangerous than most formerly-superuser-only functions. > If we can't think of a way that the lack of these checks could crash > it, then I think it's OK to remove the hardwired checks. If we can, > I'd favor keeping them. Well, there'd be an actual isolation test that they work ;-), if you override the marking. Admittedly, one test case does not prove that there's no way to crash the system, but that can be said of most parts of Postgres. regards, tom lane