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 1oxBEB-0007WM-Ng for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Nov 2022 18:09:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oxBEA-00015u-7d for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Nov 2022 18:09:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxBE9-00015k-U2 for pgsql-hackers@lists.postgresql.org; Mon, 21 Nov 2022 18:09:05 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxBE7-0008Il-Ki for pgsql-hackers@lists.postgresql.org; Mon, 21 Nov 2022 18:09:05 +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 2ALI8wsJ3219282; Mon, 21 Nov 2022 13:08:58 -0500 From: Tom Lane To: Robert Haas cc: Andres Freund , pgsql-hackers@lists.postgresql.org Subject: Re: pgsql: Prevent instability in contrib/pageinspect's regression test. In-reply-to: References: <20221121172206.h6kywxrzqcmhoqom@awork3.anarazel.de> <3214376.1669051457@sss.pgh.pa.us> <3215927.1669052115@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Mon, 21 Nov 2022 12:52:01 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3219280.1669054138.1@sss.pgh.pa.us> Date: Mon, 21 Nov 2022 13:08:58 -0500 Message-ID: <3219281.1669054138@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > On Mon, Nov 21, 2022 at 12:35 PM Tom Lane wrote: >> Hmm, so the problem is: >> >> SELECT octet_length(get_raw_page('test1', 'main', 0)) AS main_0; >> ERROR: cannot access temporary tables during a parallel operation >> >> Why in the world is get_raw_page() marked as parallel safe? >> It clearly isn't, given this restriction. > I suspect that restriction was overlooked when evaluating the marking > of this function. So it would seem. PARALLEL RESTRICTED should work, though. I'll check to see if any sibling functions have the same issue, and push a patch to adjust them. Presumably the parallel labeling has to be fixed as far back as it's marked that way (didn't look). Maybe we should push the test change further back too, just to exercise this. regards, tom lane