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 1nC60L-0006Uh-Eb for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jan 2022 20:31:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nC5zo-0002XG-P0 for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jan 2022 20:31:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nC5zo-0002X7-Fh for pgsql-hackers@lists.postgresql.org; Mon, 24 Jan 2022 20:31:24 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nC5zl-0001OA-BP for pgsql-hackers@lists.postgresql.org; Mon, 24 Jan 2022 20:31:23 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 502BA5C010B; Mon, 24 Jan 2022 15:31:20 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 24 Jan 2022 15:31:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=+j+s9h9jvBVvPwUS8G5L0RhTrMir56+9r0ozvq8Xw E4=; b=RBT774pFe9Xhd2Oq5hOEqy4qHuK9Q8T/gVG1CrousK7NMM2JETqZ8dthe 522hDrgxR6pPB4CYzIonPUfdaW5byBDMcSLIjCvfL44/GgqHe8avN631jpND2uE/ vHxnUTfDrdhDH6Gq+c7ljWnIXxyRVPI6wa8ajfY0LilpEcXAgGVQOC2HqznB/11T UfJDjMoImteEr5J+cg8pDwkxgdnZiik9xS+O/AhdcsXuI5Siqj4cZ+zWRfDxh2PJ aE9ZzA7hJa1P6/MW29bPUEH+CiVb8Lp21IkWJYSLe3KqsKXfCl+XyrpJU0EDdz0n OiPttvgEpbzizvVU7QP6VuQmLs5cA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvdejgddtgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvghtvghr ucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvghnthgvrh hprhhishgvuggsrdgtohhmqeenucggtffrrghtthgvrhhnpeefjeegheetuefhveevudel ueeftdejteeiffetvdduhfdtieefgfeutedtveeggfenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghuthes vghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 24 Jan 2022 15:31:18 -0500 (EST) Message-ID: <6b8191a0-e0f6-b204-e6c0-f7f1a5f349c0@enterprisedb.com> Date: Mon, 24 Jan 2022 21:31:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: PublicationActions - use bit flags. Content-Language: en-US To: Greg Nancarrow , Tom Lane Cc: Alvaro Herrera , Peter Smith , PostgreSQL Hackers References: <3b7f2bdd-77ed-00d7-437c-dd9c37e6a2fa@enterprisedb.com> <202112201714.ql732mnfdrtc@alvherre.pgsql> <2683410.1640048186@sss.pgh.pa.us> From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 21.01.22 01:05, Greg Nancarrow wrote: > On Tue, Dec 21, 2021 at 12:55 PM Greg Nancarrow wrote: >> >> On Tue, Dec 21, 2021 at 11:56 AM Tom Lane wrote: >>> >>> Removing this is not good: >>> >>> if (relation->rd_pubactions) >>> - { >>> pfree(relation->rd_pubactions); >>> - relation->rd_pubactions = NULL; >>> - } >>> >>> If the subsequent palloc fails, you've created a problem where >>> there was none before. >>> >> >> Oops, yeah, I got carried away; if palloc() failed and called exit(), >> then it would end up crashing when trying to use/pfree rd_pubactions >> again. >> Better leave that line in ... >> > > Attaching an updated patch to fix that oversight. > This patch thus fixes the original palloc issue in a minimal way, > keeping the same relcache structure. Why can't GetRelationPublicationActions() have the PublicationActions as a return value, instead of changing it to an output argument?