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 1mq11d-0000J7-P9 for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Nov 2021 22:46:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mq11c-0000rG-Ls for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Nov 2021 22:46:00 +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 1mq11b-0000qS-8S for pgsql-hackers@lists.postgresql.org; Wed, 24 Nov 2021 22:46:00 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mq11X-0002j0-U3 for pgsql-hackers@postgresql.org; Wed, 24 Nov 2021 22:45:58 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 101615C0116; Wed, 24 Nov 2021 17:45:53 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 24 Nov 2021 17:45:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=Uz0PIBLqOSbPneM3aRBFdsk0kS9 UQbZVM+OYQVF0ff4=; b=JtvUJ3HdWQ6cIYU/SRh8qhdygQwSfIKvt/qmprr/p1Y qROOo/eJolAbf/ZroJE9ucn5TgYRUUTK4QvpRBtVd0A4doUwSqZLAdk4ZYRPCdZW E7wGSfTzzrJI1YPvlDHsa2Wiaq8v1ssE32LvzFzPN7+GvqBexBLHeGQCCvQIlZ9J MdR1U7ryQhHCHvoEsgFtqaGZs70Q3aXCXZgk5tXn3JGz0XuNveVV05b7g2sS+aYG pQNoWuiV5s8d06N58pgcq+g5nX4VHN6iBdwjyCSbKWybMlzSvdujUgcCrW2atQpG sasfdB1TytTBbdXVuv4yAFLJ/uYGihm20xQUSdPH7og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Uz0PIB LqOSbPneM3aRBFdsk0kS9UQbZVM+OYQVF0ff4=; b=DjwGC3SwqrNGWe69Cqi/GE 7VD778RSd0/oZ+mINFRK8bysHenTcIW5Ga7pcEXmx2PP1O+y3ieEM2ZvHeQUfOIB 1xH/qAy+X97KfsbLsuKwvG2YMfDD1qM2NkS2cSwJACBc9NkHrWwcAFv74NmCsHC6 qY9eLRAbSu7l3b4kequrmuawRO9dlU1AiPwDHLd2hY3t2Bg6S0c/Vw6RVG506JW+ Lb4xITWsscGhIqQNra1qtjhpaoaRrg5AY4dLRWJeiy77S5l+rnNdFvOejPtd01qk mJVTHRzVB1tg2aLG7Vw0SDNe/AHOBHGAIBOhW7oCMjdEs0tnHU95VQKXQlmj3rLg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrgeekgdduieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdljedtmdenucfjughrpeffhffvuffkfhggtggujgesghdtreertddt vdenucfhrhhomhepofhitghhrggvlhcurfgrqhhuihgvrhcuoehmihgthhgrvghlsehprg hquhhivghrrdighiiiqeenucggtffrrghtthgvrhhnpedvgeduuefhtdeuleettdevjeeh heeiveeuieegleetgeeljeelieeuieehgeevhfenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmihgthhgrvghlsehprghquhhivghrrdighiii X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 24 Nov 2021 17:45:50 -0500 (EST) Date: Thu, 25 Nov 2021 07:45:46 +0900 From: Michael Paquier To: SATYANARAYANA NARLAPURAM Cc: Pg Hackers Subject: Re: Postgres restart in the middle of exclusive backup and the presence of backup_label file Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SqDznlTUUXc/HDVr" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --SqDznlTUUXc/HDVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 24, 2021 at 02:12:19PM -0800, SATYANARAYANA NARLAPURAM wrote: > While an exclusive backup is in progress if Postgres restarts, postgres > runs the recovery from the checkpoint identified by the label file instead > of the control file. This can cause long recovery or even sometimes fail = to > recover as the WAL records corresponding to that checkpoint location are > removed. I can write a layer in my control plane to remove the backup_lab= el > file when I know the server is not in restore from the base backup but I > don't see a reason why everyone has to repeat this step. Am I missing > something? This is a known issue with exclusive backups, which is a reason why=20 non-exclusive backups have been implemented. pg_basebackup does that, and using "false" as the third argument of pg_start_backup() would have the same effect. So I would recommend to switch to that. -- Michael --SqDznlTUUXc/HDVr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmGewJoACgkQnvQgOdby QH2Hig/8Deq0UOsMxU07zn/8vptL8kxtVpMQRTZZC6cRULoTX3iyTjU5HV+rjzBi Pam7YRjawVgEV1W8+glSwbWNlaZ1JLZGRXr6+MY+GAw7iFlTbXrqFA9z/iN27/AN wn+oJFAHdIkrXODGLTSZgFIQ0dUBJb6RAFw8PeasMSFPIcaSfruu2kRYrJ/c+jf5 pYXtaWfNkx7YFHwZDY/WCIg2APxRPm62M75Y1tOHQbC330HA6JjLlRsLCHYuS2ml r6zuCQOB8WwTImJoUmcsPSMtQeZ0kX7UrwPl0x22DGsK9HRKOYf0iatS1TjYhdue FmdT0elGrF+HYRNMjkvVlRrA/16S9zfTJ3HPEWokBWL4VjImQxOGygMEpCjMnp6l meFSLXZ8bOV8j1SnLX5V6VH9RXqFMUj/HJex1LlN0/U71hCj5F4E+AX8x+1cjiOa asHflLz9pvfNaJBsG6tPIjP85E2E0GPQJzfeap92SqmP9aVrdKw/TkMJlDM1b1KB M59kd/R/u0yP2rRGDUbtIdumcl7+Bp2sql+JHNvRMU4jRLAUiTG8lZXY49fVfRUP 0tJfKXDbCkBQD5CX26GYcdEsXFcdp1oyTCD3C00hR6+fEbe354vH5OOt1xeV2lvS y4Kd6mt3oLnULzJYShUTovlfXkQ9g+GG4dwHsbvCIHpQx+ZfXL0= =CSDH -----END PGP SIGNATURE----- --SqDznlTUUXc/HDVr--