Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vaEpk-005eBR-2g for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Dec 2025 15:06:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vaEpj-00H1Ce-1Y for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Dec 2025 15:06:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vaEpj-00H1CW-0N for pgsql-hackers@lists.postgresql.org; Mon, 29 Dec 2025 15:06:55 +0000 Received: from fhigh-b6-smtp.messagingengine.com ([202.12.124.157]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vaEpg-003PhT-2g for pgsql-hackers@lists.postgresql.org; Mon, 29 Dec 2025 15:06:55 +0000 Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfhigh.stl.internal (Postfix) with ESMTP id B18717A0076; Mon, 29 Dec 2025 10:06:50 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-10.internal (MEProxy); Mon, 29 Dec 2025 10:06:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kurilemu.de; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to; s=fm3; t=1767020810; x= 1767107210; bh=sgyU54MkC8PU9N+GfI2uXVRcOouJgMpXiZ9DbDYwqDs=; b=I 3iXvbmF7AJAsvJ9zqNH09uAusMYnRlCweHPE0/BapPuWp9YKRpPZ28Zbuib50WDi Fr4AHbGBmgnG4BbOCF4M6oTFcdaW+ji5I7nV47rsaHHzDQFr1L23ac/w3B9B07Qy tlzugnFfVz7y9bPCZuOokuQrGh/r9U5uvJO4g/mdHMHbwxkcY4lkRmuai3o9Y3Au SEJ2nGx5Azw4O1nxFtFbjZYEMec/jAbZFosRRQg+LTHTPRux7ZQSoPUJfhmj5QZ6 RLkZmeAya1p7ZlCGUycNA4wL4lR0fxs0E73x0vbqsIkVf3EuTGhpejCn1qqMyuf7 +TUbOzqwZ1/3vztm3QvvA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1767020810; x=1767107210; bh=s gyU54MkC8PU9N+GfI2uXVRcOouJgMpXiZ9DbDYwqDs=; b=u3ikzb3sE/uuZybQr z+Io/7wQlhkfay+6UKtpLftwWV8rTyuRgmTNx7LUtnc09vIJkjrrF1CSKnxUgnpY a6k0RtL9wknorLNaCUTfgMBERezFoF6YOETaDJaE2TSFr2kTqV2zFgF8WZjlU7sn ROftPaKWCKmd1EyLQDZ+jytuMkooXwLc8UrQVj83MBuDM68KQr3zP6PsidgGEqhR c9RGckU4iC5QzxwK0dKeOx7R1hxgltNM3O25tZluYhQajYoaXlJlOVoMV7a2/LIG gLEGHTlYN8+6dYX6cp1jvSjoO0A7VopVh0ddd1ATCJeGmnXvazrV/iCUB6MJ8R1W ZWPTw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdejjeegiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpemllhhvrghrohcu jfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgeskhhurhhilhgvmhhurdguvgeqnecuggftrf grthhtvghrnhepteeuvdehffekvefgueehveetveekgfegtddtueefueehuddutdfhfeff hfejfeffnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvges khhurhhilhgvmhhurdguvgdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouh htpdhrtghpthhtoheprghshhhuthhoshhhrdgsrghprghtrdhoshhssehgmhgrihhlrdgt ohhmpdhrtghpthhtoheplhhirdgvvhgrnhdrtghhrghosehgmhgrihhlrdgtohhmpdhrtg hpthhtohepphhgshhqlhdqhhgrtghkvghrsheslhhishhtshdrphhoshhtghhrvghsqhhl rdhorhhg X-ME-Proxy: Feedback-ID: ie3de48e3:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 29 Dec 2025 10:06:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kurilemu.de; s=schmee; t=1767020445; bh=iDX9BHCEdzM4+Dacw7UpBr/LvqAqbLlONVZ60mg3GNo=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=vehgUWmiG5iTS7l+VC+lLbcGBWVhZoRTyK0tUaTNPQ/rSqs3p/QvPTxb4QH3m/R7E zGDiYSxzk7AavJdO2qmKbc90uot7ZstxGPmxBmoqmoLTztIU4mkagleWjKFaNCmmU1 o8kcT9MoUEDP8ymJf3qLJ3rQOnGLjdPC5Lh8d3hLDwEISllWho/YqHhdANQSRfItTe rId9LJ1tpihv5pOvmWW7zEcTulcnimlBfeKmClbRfAefO8Ist3C77NIcHXoAEUA0He P0VKVfkBl1HLwOP1kMgKTm9ccXL0Kkk+VDIrW2j+ksDDgK6RzEE3/ib4RQxVUmcRcO yUDD+DnQdsPyw== Received: by schmee.kurilemu.internal (Postfix, from userid 1000) id C582278; Mon, 29 Dec 2025 16:00:45 +0100 (CET) Date: Mon, 29 Dec 2025 12:00:45 -0300 From: =?utf-8?Q?=C3=81lvaro?= Herrera To: Ashutosh Bapat Cc: Chao Li , Postgres hackers Subject: Re: Refactor replication origin state reset helpers Message-ID: <202512291457.jy7mlturovmy@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202512291435.5edkf3hnichv@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2025-Dec-29, Álvaro Herrera wrote: > On 2025-Dec-24, Ashutosh Bapat wrote: > > It's also quite easy to confuse between these functions and > > replorigin_session_reset(). It's not clear where the boundaries of the > > latter end and where those of the new ones start. I think the latter > > deals with the shared memory structures while the new ones deal with > > the backend local state. And then there's replorigin_reset() which > > adds to the confusion. That function doesn't call > > replorigin_session_reset() which the other two callers of > > replorigin_session_clear_state() call. Why? I think there is more to > > clean here than what's in the patch. That doesn't mean that we cannot > > accept this patch without larger cleanup, but it should not add to the > > existing confusion. I think we should just rename the worker.c function to have a less generic-sounding name (so that it becomes more obvious that it's a worker.c-specific function); have both replorigin_session_clear_state() and replorigin_xact_clear_state() be a single function, with a boolean flag to indicate whether to reset replorigin_session_origin or not; and have replorigin_session_reset() call replorigin_session_clear_state() internally rather than require every single of its callers do it separately, which IMO makes no sense. With these three changes I think the code would become quite clear. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest "foo" someone someday shall type "supercalifragilisticexpialidocious" (5th Commandment for C programmers)