Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxD9T-000571-6e for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Nov 2022 20:12:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oxD9S-0005gu-0q for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Nov 2022 20:12:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxD9R-0005gb-O1 for pgsql-hackers@lists.postgresql.org; Mon, 21 Nov 2022 20:12:21 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxD9P-0008C9-HL for pgsql-hackers@lists.postgresql.org; Mon, 21 Nov 2022 20:12:20 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2ALKCFBT3264595; Mon, 21 Nov 2022 15:12:15 -0500 From: Tom Lane To: Andres Freund cc: Robert Haas , pgsql-hackers@lists.postgresql.org Subject: Re: pgsql: Prevent instability in contrib/pageinspect's regression test. In-reply-to: <20221121195628.2rlqpbkjgjsvqn6w@alap3.anarazel.de> References: <20221121172206.h6kywxrzqcmhoqom@awork3.anarazel.de> <3214376.1669051457@sss.pgh.pa.us> <3215927.1669052115@sss.pgh.pa.us> <20221121195628.2rlqpbkjgjsvqn6w@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Mon, 21 Nov 2022 11:56:28 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3264593.1669061535.1@sss.pgh.pa.us> Date: Mon, 21 Nov 2022 15:12:15 -0500 Message-ID: <3264594.1669061535@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > On 2022-11-21 12:52:01 -0500, Robert Haas wrote: >> On Mon, Nov 21, 2022 at 12:35 PM Tom Lane wrote: >>> Why in the world is get_raw_page() marked as parallel safe? >>> It clearly isn't, given this restriction. > It's somewhat sad to add this restriction - I've used get_raw_page() (+ > other functions) to scan a whole database for a bug. IIRC that actually > did end up using parallelism, albeit likely not very efficiently. > Don't really have a better idea though. Me either. > It may be worth inventing a framework where a function could analyze its > arguments (presumably via prosupport) to determine the degree of > parallel safety, but this doesn't seem sufficient reason... Maybe, but in this example you could only decide you were parallel safe if the argument is an OID constant, which'd be pretty limiting. If I were trying to find a better fix I'd be looking for ways for parallel workers to be able to read the parent's temp tables. (Perhaps that could tie in with the blue-sky discussion we had the other day about allowing autovacuum on temp tables??) regards, tom lane