Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHTbg-0000Rb-6J for pgsql-admin@arkaria.postgresql.org; Tue, 30 Oct 2018 12:58:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gHTbc-0007Bi-OG for pgsql-admin@arkaria.postgresql.org; Tue, 30 Oct 2018 12:58:48 +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 1gHTbc-0007BW-Gy for pgsql-admin@lists.postgresql.org; Tue, 30 Oct 2018 12:58:48 +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 1gHTba-00066R-65 for pgsql-admin@postgresql.org; Tue, 30 Oct 2018 12:58:48 +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 w9UCwc0H012416; Tue, 30 Oct 2018 08:58:38 -0400 From: Tom Lane To: Axel Rau cc: Laurenz Albe , pgsql-admin@postgresql.org Subject: Re: Getting fancy errors when accessing information_schema on 10.5 In-reply-to: <97862736-B0B4-4FE6-8A6C-18CDB70C6F96@Chaos1.DE> References: <4880e067723cefc1dc2e08a117f96de26ae0f797.camel@cybertec.at> <44D4C7B1-0DCF-4166-9DB8-B5D75EB2985E@Chaos1.DE> <20191.1540901834@sss.pgh.pa.us> <97862736-B0B4-4FE6-8A6C-18CDB70C6F96@Chaos1.DE> Comments: In-reply-to Axel Rau message dated "Tue, 30 Oct 2018 13:31:29 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12414.1540904318.1@sss.pgh.pa.us> Date: Tue, 30 Oct 2018 08:58:38 -0400 Message-ID: <12415.1540904318@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Axel Rau writes: >> Am 30.10.2018 um 13:17 schrieb Tom Lane : >> It doesn't happen for me either. Looking at the planner code, it seems >> like the relkind check should happen first because it'd be cheaper than >> the OR condition. Have you perhaps messed with the cost attributed to >> pg_has_role(), has_sequence_privilege(), or chareq()? > Not by intention. The instance has some history, it go back to 8.x I think. >> You could investigate with, eg, >> >> select oid::regprocedure, procost from pg_proc >> where proname = 'has_sequence_privilege'; > nextcloud=> select oid::regprocedure, procost from pg_proc > nextcloud-> where proname = 'has_sequence_privilege'; > oid | procost > ----------------------------------------+--------- > has_sequence_privilege(name,text,text) | 1 > has_sequence_privilege(name,oid,text) | 1 > has_sequence_privilege(oid,text,text) | 1 > has_sequence_privilege(oid,oid,text) | 1 > has_sequence_privilege(text,text) | 1 > has_sequence_privilege(oid,text) | 1 > (6 rows) Hm, nothing surprising there, but what about the other two? regards, tom lane