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 1oiw9t-0001UU-00 for pgsql-hackers@arkaria.postgresql.org; Thu, 13 Oct 2022 11:13:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oiw9q-0001TB-Ht for pgsql-hackers@arkaria.postgresql.org; Thu, 13 Oct 2022 11:13:46 +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 1oiw9p-0001SK-Jf for pgsql-hackers@lists.postgresql.org; Thu, 13 Oct 2022 11:13:46 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oiw9h-0000WY-Gn for pgsql-hackers@lists.postgresql.org; Thu, 13 Oct 2022 11:13:45 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 6B2CA32005CA; Thu, 13 Oct 2022 07:13:33 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 13 Oct 2022 07:13:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1665659613; x=1665746013; bh=8 XNqwHaLnwh6NY8/I9K3ExxfKiXZpyjyl+Yii21IBFs=; b=V+KFXGERWT0MRYysh 4mkGpREOfaW9POlKuF+pPbfjHzczGIAzdp4hOVrgpgjeUQgYJNyZRqTY/2UhFtTN YZIjWJpXU5paY26m7/LQqAzxNbolpY0FKurQVYU47KhMA/d/A8RVWX+PCPKPtUPb Mja5E1cX3lZVDEuItGZQCDySPO17Tur0mpYP8EbOV9wZOrFh2jMfonToTvAbrb2l dsNmSg/OVlUagqXaTzpG7JIehH4XhAxlkXR4BYT02xKBzazYapNTfQ3QgM77GJHN SstdYFzdmtQR/vLaff86LTZFktBt+mXiNqLm+XIOxDxrFJcKUF/uF/Sd4SVTq4b8 qtLbQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeektddggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 13 Oct 2022 07:13:32 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 5C16366; Thu, 13 Oct 2022 13:13:30 +0200 (CEST) Date: Thu, 13 Oct 2022 13:13:30 +0200 From: Alvaro Herrera To: Bharath Rupireddy Cc: Andres Freund , Michael Paquier , Nathan Bossart , PostgreSQL Hackers Subject: Re: Move backup-related code to xlogbackup.c/.h Message-ID: <20221013111330.564fk5tkwe3ha77l@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Oct-13, Bharath Rupireddy wrote: > Hm. Agree. But, that requires us to include xlogbackup.h in > xlog_internal.h for SessionBackupState enum in > ResetXLogBackupActivity(). Is that okay? It's not great, but it's not *that* bad, ISTM, mainly because xlog_internal.h will affect less stuff than xlog.h. > SessionBackupState and it needs to be set before we release WAL insert > locks, see the comment [1]. I see. Maybe we could keep that enum in xlog.h, instead. While looking at how that works: I think calling a local variable "session_backup_state" is super confusing, seeing that we have a file-global variable called sessionBackupState. I recommend naming the local "newstate" or something along those lines instead. I wonder why does pg_backup_start_callback() not change the backup state before your patch. This seems a gratuitous difference, or is it? If you change that code so that it also sets the status to BACKUP_NONE, then you can pass a bare SessionBackupState to ResetXLogBackupActivity rather than a pointer to one, which is a very strange arrangement that exists only so that you can have a third state (NULL) meaning "don't change state" -- that looks quite weird. Alternatively, if you don't want or can't change pg_backup_start_callback to pass a valid state value, another solution might be to pass a separate boolean "change state". But I would look at having another patch before your series that changes pg_backup_start_callback to make the code identical for the three callers, then you can simplify the patched code. > Should we just remove the > SessionBackupState enum and convert SESSION_BACKUP_NONE and > SESSION_BACKUP_RUNNING to just macros in xlogbackup.h and use integer > type to pass the state across? I don't know what's better here. Do you > have any thoughts on this? No, please, no passing of unadorned magic numbers. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/