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 1w2OUQ-000FWa-1X for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Mar 2026 07:05:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w2OUO-00GsqJ-07 for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Mar 2026 07:05:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w2OUN-00Gsq8-2J for pgsql-hackers@lists.postgresql.org; Tue, 17 Mar 2026 07:05:15 +0000 Received: from dragonfly.birch.relay.mailchannels.net ([23.83.209.51]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w2OUJ-0000000099J-3g58 for pgsql-hackers@postgresql.org; Tue, 17 Mar 2026 07:05:14 +0000 X-Sender-Id: hostingeremail|x-authuser|david@pgbackrest.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id B47AB8C18B9; Tue, 17 Mar 2026 07:05:11 +0000 (UTC) Received: from fr-int-smtpout12.hostinger.io (100-116-110-109.trex-nlb.outbound.svc.cluster.local [100.116.110.109]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 746818C1AA3; Tue, 17 Mar 2026 07:05:10 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; d=mailchannels.net; s=arc-2022; cv=none; t=1773731111; b=W5+u9i8WX6Kxi/gw9XKDqJcWagnmSfSlrXLeEUj8OLjkY6BpdaBNYyodspxwGP3Rglur6P 1YoKXxRQs5jtwEqf7Uq/dDWtd7eww+k8y3qfH3KAdStPPQzxyUuV7YrN18OpZ/537HuszY rW3C0tNGAtJt8f2ku7xz0DUwt8tBR9GaDYS5KeBeJZHVSV20ON8KDb3YOOEFsaxxVLKhol /uSTaWXmxfOlaU08G86roySnMjZvVtZ38x3rZ90Z8fsYzbciQQhnITYfRg/LAZD41BM9NM 61S6jU8xrTgjdj/wBVAn80v8d7u6hcf1/Jn7pW7kXB+dT0yTd5rWgTcJy1n4Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1773731111; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/jZ/Dok1/MtAuiFEZRQLHWzh9gg/tsGljuhjJ/a4yPI=; b=Vc3eyBmWL/kDeVlLTDoPVJhlDmCk2LqKD2VcH/IPqgrgjx93HnIMhPCEB5ZvJWRhVY0xp2 Ye6OCJaH6Qr1nhftljuYlbmw9sStqmL/IuRfn6hnUHtZkW7AiLuSS2plPhdHMPZ/HimeKt 3RrdXiSBVvWopuL42J49q7Bz3CYQOFJOFrVYZTRpiOPdQ/WIslDLTpBy25BdRcmRi4Vlaj Xo2ZJDN8CzGetDBHkdmnTzZgfyGajxPqE39FiIAI9PQQKDHHbfBuDNaIHIj7ibe6ibcaaD RCthHLr9P0DUooNJcJD1rCIVeoIsiYHGAa7ddbjrmqs+vuM1ANH1MI6GFwAonA== ARC-Authentication-Results: i=1; rspamd-5b467f8f49-h2jrz; auth=pass smtp.auth=hostingeremail smtp.mailfrom=david@pgbackrest.org X-Sender-Id: hostingeremail|x-authuser|david@pgbackrest.org X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authuser|david@pgbackrest.org X-MailChannels-Auth-Id: hostingeremail X-Trade-Imminent: 4fe563ab29934211_1773731111540_856055571 X-MC-Loop-Signature: 1773731111540:484259421 X-MC-Ingress-Time: 1773731111539 Received: from fr-int-smtpout12.hostinger.io (fr-int-smtpout12.hostinger.io [148.222.54.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.116.110.109 (trex/7.1.5); Tue, 17 Mar 2026 07:05:11 +0000 Received: from [10.5.0.2] (unknown [194.113.66.169]) (Authenticated sender: david@pgbackrest.org) by smtp.hostinger.com (smtp.hostinger.com) with ESMTPSA id 4fZjdZ68Hwz1xmm; Tue, 17 Mar 2026 07:05:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgbackrest.org; s=hostingermail1; t=1773731108; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/jZ/Dok1/MtAuiFEZRQLHWzh9gg/tsGljuhjJ/a4yPI=; b=HNeZMUY91MR47uRrv28fJDAfQwwfpkeai6zx9MMgrd00j6FnAFbYieyGSHbdy/anWukkBC EIvhNiJ/o1NNyFCmXn938rjK3JSCGV6gli0lxVwUDPbwvwkPB4BOhVknINGzRMJ9EThwQc /4u++smWkap8uASGcI+NiSREEH8ZuuJTUqp5q9XFOIOCICT+VYoRTB2zkeQGJmlWq1HlC4 eNHuSVlfzmltJBbRK+a1RUtuQFdQoZOxvZS32iWFA1WYZWrwklMcHwfTWdlQQckXw3000t I00MsImznwljzdrJXfHT/BWVGvs+vxHrNR6eLBqxJloi71ATLPMaNfHPLlCJlQ== Message-ID: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Return pg_control from pg_backup_stop(). To: Haibo Yan Cc: Michael Paquier , Pg Hackers References: <83f5295e-082d-432c-92a4-365707bd2296@pgbackrest.org> <1248c005-b693-494a-8d7a-68bc7d482679@pgbackrest.org> <8b8aa673-fcef-4e14-a05d-0885283ef1b8@pgbackrest.org> <17DC1346-0CDE-4E39-B110-3D6FB0797AC6@gmail.com> Content-Language: en-US From: David Steele In-Reply-To: <17DC1346-0CDE-4E39-B110-3D6FB0797AC6@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 17 Mar 2026 07:05:06 +0000 (UTC) X-CM-Envelope: MS4xfAU+R46hpetnRCQEfcrRCcivuYg6pQxpry5GM16VVrjmOurHn8bW/KEIadI51THuOEBjXrHt063I617XTo92+MIKhb1cKy2Qw9Q82rfVmJ6xWtKLAnCt TLVB/7RWrkWRaOW0s7qx8IVa9FDj1HZXGgzZSOy7disKTke7cczK+XotmcjCLfdEcOgnLSOw6zfjAhA5H7pbJlPD1xyB/+TuelkKuhgH31wwZP+dHLS+rWcf lZFUNsSjXxaMaIhRb/trLHWVy3750bnBpMKBfW6n9ds= X-CM-Analysis: v=2.4 cv=UN2PHzfy c=1 sm=1 tr=0 ts=69b8fd24 a=37GlHLlmPwC4rI/0ZJ0JhQ==:117 a=37GlHLlmPwC4rI/0ZJ0JhQ==:17 a=IkcTkHD0fZMA:10 a=eohg35DXGq9C8Za02pAA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 X-AuthUser: david@pgbackrest.org List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 3/17/26 12:16, Haibo Yan wrote: > I have not read the code yet, so this may already be answered there, but > I had a question about the proposal itself. This patch protects against > a missing backup_label, but what about a wrong one? If a user restores a > backup_label file from a different backup, the existence check alone > would not detect that. Do we need some consistency check between the > returned pg_control copy and the backup_label contents, or is the > intended scope here limited to the “missing file” case only? Thank you for having a look! The goal here is only to check for a missing backup_label. The general problem is that PostgreSQL suggests that removing backup_label might be a good idea so the user does it: If you are not restoring from a backup, try removing the file \"%s/backup_label\" The user *could* copy a backup_label from another backup and there are ways we could detect that but I feel that should be material for a separate patch. Regards, -David