Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dsvxT-00035K-KU for pgsql-committers@arkaria.postgresql.org; Fri, 15 Sep 2017 19:07:23 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dsvxT-0005si-2W for pgsql-committers@arkaria.postgresql.org; Fri, 15 Sep 2017 19:07:23 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dsvxS-0005sC-FQ for pgsql-committers@postgresql.org; Fri, 15 Sep 2017 19:07:22 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dsvxP-00044F-L1 for pgsql-committers@postgresql.org; Fri, 15 Sep 2017 19:07:21 +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 v8FJ7EV7031857; Fri, 15 Sep 2017 15:07:14 -0400 From: Tom Lane To: Andres Freund cc: Thomas Munro , pgsql-committers Subject: Re: pgsql: Add support for coordinating record typmods among parallel worke In-reply-to: <20170915181436.u6j27rx65giyntmk@alap3.anarazel.de> References: <13971.1505445491@sss.pgh.pa.us> <14932.1505447120@sss.pgh.pa.us> <29888.1505451575@sss.pgh.pa.us> <21075.1505486017@sss.pgh.pa.us> <20170915181436.u6j27rx65giyntmk@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Fri, 15 Sep 2017 11:14:36 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31855.1505502434.1@sss.pgh.pa.us> Date: Fri, 15 Sep 2017 15:07:14 -0400 Message-ID: <31856.1505502434@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 Andres Freund writes: > On 2017-09-15 10:33:37 -0400, Tom Lane wrote: >> 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.) > How'd it reuse it after running the detach hook in workers? Resetting NextRecordTypmod to zero means that we could reuse a typmod that was previously used. Maybe that's safe because no memory of the old record definition exists anywhere else in the process, but I'm not exactly convinced of that. For that matter, I'm not exactly convinced that nothing else is holding on to an actual pointer to the record tupdesc, making it moot whether or not we flush typcache.c's pointer. (I'm pretty sure that plpgsql, for one, might hold onto tupdesc pointers it gets from the typcache. That's why they have refcounts in the first place.) There's never previously been any expectation that record typmod registrations weren't good for the life of the process, so I don't trust any of the assumptions this code wants to make. It's moot as long as we're not reusing workers, anyway: nothing is going to touch any of the record-tupdesc data before process exit. 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