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 1mnm5U-0005YQ-6F for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Nov 2021 18:24:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mnm5S-0006hJ-JR for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Nov 2021 18:24:42 +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 1mnm5S-0006hA-9v for pgsql-hackers@lists.postgresql.org; Thu, 18 Nov 2021 18:24:42 +0000 Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mnm5K-00065x-TK for pgsql-hackers@postgresql.org; Thu, 18 Nov 2021 18:24:41 +0000 Received: by mail-io1-xd35.google.com with SMTP id m9so9340192iop.0 for ; Thu, 18 Nov 2021 10:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ekS8s0EHHiQHyTLUHfAPk/Zz3AIXl7M06QBBWexAFMU=; b=bDSYcrhbLimeRNEu0RKiQ12pNv0+x/CgQAKBZG3Tis0BcoMmipSwMDvu8FBmwpDkyV 8J2IrjC9u9DziBOcMvmclgIrOLlJaTNmugHUNs+FKFKfE/t9SfeF2yWfETF8GQsGW2vG eGZMvZdeHECysFC5SIzy/iHcYlJtbw4+86k+NOpnPSIHAgeJEXiPf0AGu3W6clKXNGjV 2+TFGNfdZb8FeodbFzqEMrzrwQu3xYw3WfZgtlVxbetCPgyasJgHpuYr0Vjrl8/wZ23a xB0O6n0m8x991nTBbaKh5NLc2ZamVRXidE7AyaeyQ3HxWJg7fVWTvywhAoFo8ShU2By4 Ulyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ekS8s0EHHiQHyTLUHfAPk/Zz3AIXl7M06QBBWexAFMU=; b=cbUpnhap6Bg74J4nVwbK909kiiy2hh/TfDV+LJAFu8Pb5pxafvlcR7F25Jl4WBiGce z14qgY8eAZqGHKVZvX03V1wUUUq9t2Ek29krPVuGIDIXZk5GXyznSA0DD4O0bse/mf3U srla74tQM0V+RnV++oFMMNk//vP6w0+JagfAw08T6bG5ROnZjVENFpQb8+MnxS4SZVPS ejsHAzSEn42IgNHR5jtBtCiOyJSyQ8AwH9r83zkWKhtKD7JZLpvJ9Hg7cKnarGJh28Sn YsaROvQ3dnR1yrOrL3zays6CUsTappeVE7yiN1fxw9oE/s4fdWJGv3ioCw3W3YqpRUNH KlfA== X-Gm-Message-State: AOAM533xca7ISR+LKSc3QU05F7qfcyKSFvaZNGfc7AiIy3qoXJ3cMOgq 6JAxlKRXzeslRvMky3/5kbp2TpnKGelYDw== X-Google-Smtp-Source: ABdhPJzJBFyMHrj6/4gGvrC5tFBe/ACXiJWvHiDL56dFdXYSAm9iLrcG2mMneImLsOQVcBIKC7i8FQ== X-Received: by 2002:a05:6638:2257:: with SMTP id m23mr22376216jas.17.1637259872327; Thu, 18 Nov 2021 10:24:32 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id r14sm465672iov.14.2021.11.18.10.24.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Nov 2021 10:24:32 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id F2C47800CCF; Thu, 18 Nov 2021 12:24:30 -0600 (CST) Date: Thu, 18 Nov 2021 12:24:30 -0600 From: Justin Pryzby To: Melanie Plageman Cc: pgsql-hackers@postgresql.org, Andres Freund , Alvaro Herrera Subject: Re: make tuplestore helper function Message-ID: <20211118182430.GO17618@telsasoft.com> References: <20211102202353.GG17618@telsasoft.com> <20211108201338.GU17618@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Nov 18, 2021 at 12:59:03PM -0500, Melanie Plageman wrote: > On Mon, Nov 8, 2021 at 3:13 PM Justin Pryzby wrote: > > On Mon, Nov 08, 2021 at 02:52:28PM -0500, Melanie Plageman wrote: > > > On Tue, Nov 2, 2021 at 4:23 PM Justin Pryzby wrote: > > > > > > > > Several places have a conditional value for the first argument (randomAccess), > > > > but your patch changes the behavior to a constant "true". I didn't review the > > > > patch beyond that. > > > > ... > > > I believe the patch has preserved the same behavior. All of the callers > > > for which I replaced tuplestore_begin_heap() which passed a variable for > > > the randomAccess parameter had set that variable to something which was > > > effectively the same as passing true -- SFRM_Materialize_Random. > > > > I don't think so ? > > > > They callers aren't passing SFRM_Materialize_Random, but rather > > (allowedModes & SFRM_Materialize_Random) != 0 > > > > Where allowedModes is determined EXEC_FLAG_BACKWARD. ... > You are right. I misread it. > > So, I've attached a patch where randomAccess is now an additional > parameter (and registered for the next fest). > > I was thinking about how to add a test that would have broken when I > passed true for randomAccess to tuplestore_begin_heap() when false was > required. But, I don't fully understand the problem. If backward > accesses to a tuplestore are not allowed but randomAccess is mistakenly > passed as true, would the potential result be potentially wrong results > from accessing the tuplestore results backwards? No, see here src/backend/utils/fmgr/README-The Tuplestore must be created with randomAccess = true if src/backend/utils/fmgr/README:SFRM_Materialize_Random is set in allowedModes, but it can (and preferably src/backend/utils/fmgr/README-should) be created with randomAccess = false if not. Callers that can support src/backend/utils/fmgr/README-both ValuePerCall and Materialize mode will set SFRM_Materialize_Preferred, src/backend/utils/fmgr/README-or not, depending on which mode they prefer. If you use "randomAccess=true" when it's not needed, the result might be less efficient. Some callers specify "true" when they don't need to. I ran into that here. https://www.postgresql.org/message-id/21724.1583955158@sss.pgh.pa.us Maybe you'd want to add an 0002 patch which changes those to conditional ? BTW, there should be a newline before MakeFuncResultTuplestore(). -- Justin