Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jCMhD-0005Jd-1h for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Mar 2020 12:12:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jCMhB-0003wh-Up for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Mar 2020 12:12:13 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1jCMhB-0003sn-MM for pgsql-hackers@lists.postgresql.org; Thu, 12 Mar 2020 12:12:13 +0000 Received: from mail-qv1-xf34.google.com ([2607:f8b0:4864:20::f34]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jCMh9-00065d-6Q for pgsql-hackers@postgresql.org; Thu, 12 Mar 2020 12:12:13 +0000 Received: by mail-qv1-xf34.google.com with SMTP id w5so2434130qvp.11 for ; Thu, 12 Mar 2020 05:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=rTgDHytomtElCRUsW+ArOGOQgFicRWsEAKskDJquAzE=; b=wCQgY7l11YqIKlleEKWFMpbV82veF0Zpv6aQAkCP5pB0GWON+c6xVPCkJR84hbKxUw qVFVhhuaxEH72EK0b8j+s+OVRVgSPv5fTDixN2qJYnUWYUSv66rSdqKoURVYt+d9EKEh bBFiDSHr6ET0VjYSzPCkH+m5P+9ioHt/duthWWsvCBjjS41c5SyoQYwvyPtJRnIIQ1/H 0B+4unjS4qxf8lIPIFT+phjvpj6FGw03Wg/+hfEpvmZYSHIi5GXcOj0JSlocEYxBskKi ykoRu+VLw3mo8jgTDuGgPwf3sZYOWZGdOETjyE37jnLTdh7ngalyQzthxiZZDQCGALbM WpFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rTgDHytomtElCRUsW+ArOGOQgFicRWsEAKskDJquAzE=; b=tTyiaxx1KQpn/VVlglUfiOdP8KpMN7OISTkk7EkaLkjAK40Fl+cqQF3sfbVHNkEC29 T5ZLkf+04pKnm9d5gcX+XDF6VGp+Ju9xFgohEJJcoEeSUXtSWwBYhKfgmMyDsSMUVy1W LG1esa0O5KAJwQJEvi1xxeZwIzhTqka4qW1OgVyYup2QUSbQCQ9NiyFVG8zQBoHayLnw WBBD63FR1eDsXQd0yUW+yq0SMZrVq7+qo+V1Ap3P3f355nearovI4NkEA2DTXRnWGkOw S8aFMY1kSHKOOuJOJpdPo5UTNXRG3OMRXirG54/5TQaGXh8vNC5J9yqZ1o+gaqTFpxFv RWkg== X-Gm-Message-State: ANhLgQ00/VYKQYPjuPUTmYdkGLihI6dLQT6w/BUOlA82DKWb6avywwBl y3qEU7fdCRx73BsQ8819iMGH4A== X-Google-Smtp-Source: ADFU+vtMGv+UDbYaViuQmvFDf85fdJbFDOMG8XY9j/5vPWWelpvn+5Qhx0k3NL2GJCe03d+0RPP2XA== X-Received: by 2002:a05:6214:90c:: with SMTP id dj12mr6990185qvb.149.1584015128980; Thu, 12 Mar 2020 05:12:08 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id a141sm27488894qkb.50.2020.03.12.05.12.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2020 05:12:08 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 12B39800964; Thu, 12 Mar 2020 07:12:07 -0500 (CDT) Date: Thu, 12 Mar 2020 07:12:06 -0500 From: Justin Pryzby To: Tom Lane Cc: pgsql-hackers@postgresql.org, Fabien COELHO , Alvaro Herrera , David Steele , "Bossart, Nathan" , Thomas Munro Subject: Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction Message-ID: <20200312121206.GC29065@telsasoft.com> References: <20200308173103.GC1357@telsasoft.com> <27334.1583692669@sss.pgh.pa.us> <20200308191456.GD1357@telsasoft.com> <5679.1583696409@sss.pgh.pa.us> <8034.1583699444@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8034.1583699444@sss.pgh.pa.us> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Mar 08, 2020 at 04:30:44PM -0400, Tom Lane wrote: > BTW, another thing I noticed while looking around is that some of > the functions using SRF_RETURN_DONE() think they should clean up > memory beforehand. This is a waste of code/cycles, as long as the > memory was properly allocated in funcctx->multi_call_memory_ctx, > because funcapi.c takes care of deleting that context. > > We should probably document that *any* manual cleanup before > SRF_RETURN_DONE() is an antipattern. If you have to have cleanup, > it needs to be done via RegisterExprContextCallback instead. This part appears to be already in place since e4186762ffaa4188e16702e8f4f299ea70988b96: |The memory context that is current when the SRF is called is a transient |context that will be cleared between calls. This means that you do not need to |call pfree on everything you allocated using palloc; it will go away anyway. |However, if you want to allocate any data structures to live across calls, you |need to put them somewhere else. The memory context referenced by |multi_call_memory_ctx is a suitable location for any data that needs to survive |until the SRF is finished running. In most cases, this means that you should |switch into multi_call_memory_ctx while doing the first-call setup. -- Justin