Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dsrgv-0001td-5M for pgsql-committers@arkaria.postgresql.org; Fri, 15 Sep 2017 14:34:01 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dsrgu-00082s-OB for pgsql-committers@arkaria.postgresql.org; Fri, 15 Sep 2017 14:34: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_2) (envelope-from ) id 1dsrgf-0007Xr-Ia for pgsql-committers@postgresql.org; Fri, 15 Sep 2017 14:33:45 +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_2) (envelope-from ) id 1dsrgc-0006oi-9q for pgsql-committers@postgresql.org; Fri, 15 Sep 2017 14:33:45 +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 v8FEXbpA021076; Fri, 15 Sep 2017 10:33:37 -0400 From: Tom Lane To: Thomas Munro cc: Andres Freund , pgsql-committers Subject: Re: pgsql: Add support for coordinating record typmods among parallel worke In-reply-to: References: <13971.1505445491@sss.pgh.pa.us> <14932.1505447120@sss.pgh.pa.us> <29888.1505451575@sss.pgh.pa.us> Comments: In-reply-to Thomas Munro message dated "Fri, 15 Sep 2017 18:47:10 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21074.1505486017.1@sss.pgh.pa.us> Date: Fri, 15 Sep 2017 10:33:37 -0400 Message-ID: <21075.1505486017@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-committers Precedence: bulk Sender: pgsql-committers-owner@postgresql.org Thomas Munro writes: > Yeah. The regress tests in d36f7efb39e1b9613193b2e12717dbe2418ddae5 > tested this stuff in parallel mode, but only a happy case to > demonstrate blessed RECORD types travelling through tqueue.c correctly > before and after ripping out the remapping stuff. The problem here > was that I do some cleanup in the DSM detach hook of the new session > segment, and that involved reading data that could point to another > segment (if the DSA area needed more space). That can blow up if that > other segment happens to have been unmapped first in the arbitrary > order of resource cleanup in an aborting worker. I do have some > thoughts on how to solve that general problem, but in this case it's > completely unnecessary anyway. The attached patch fixes the problem > by getting rid of the code that accesses shmem in the detach hook. > With this patch applied installcheck survives on a cluster with > force_parallel_worker=regress. I don't much like your proposed comment; the only way that this code is even approximately correct is if we're exiting the process and will never touch the RecordCacheArray again. (Otherwise, it risks reassigning a previously used local typmod.) My inclination is to just leave the local data structures alone. There's nothing we can do to them that doesn't create more problems than it solves, if the process continues to use the cache. regards, tom lane -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers