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.94.2) (envelope-from ) id 1sUqxq-006C7Y-GF for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jul 2024 17:00:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sUqxo-002L0l-L4 for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jul 2024 17:00:13 +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.94.2) (envelope-from ) id 1sUqxo-002L0d-9X for pgsql-hackers@lists.postgresql.org; Fri, 19 Jul 2024 17:00:12 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sUqxl-000PeT-Cg for pgsql-hackers@postgresql.org; Fri, 19 Jul 2024 17:00:12 +0000 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-52ed741fe46so2450268e87.0 for ; Fri, 19 Jul 2024 10:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721408408; x=1722013208; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1l27KG6E+PxrOXE3JFJW5p8ZCZS3pRYfzYYF/jObhp4=; b=cR5m7wzE41BBACD8SuOV/X8+mZe7ZGZBHzRomMdWG9AsE5CURhe3AGShkXZx5bvhra X/HG3KXTj1zSXI1u03zodgOQV6dGZnzYLIpncdGudQA/Jp/QjWOX/kcwTEmKrz9aDsz3 4jF/jGIKfMuop+nGuJl4SWPUizmvarPxuqGMLCNwIkbv/UwFWDZKMFlZTeWi2TZOLt51 Hi23w4EpSa1n2xnUNjkjNRf1/Nb08ZXBwPYRHPBx89h4w+KKeC3TesdwhGyjRU03U1Jq pEgsz6d0ZXxhkY6SreAiMvoKHMcNV6r1m6JS781/aeHZqKn1cIIANUuRrjN7ecS28f80 AOcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721408408; x=1722013208; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1l27KG6E+PxrOXE3JFJW5p8ZCZS3pRYfzYYF/jObhp4=; b=HuRUH4FupmRjvnn+JscERlhh3gh6DfiZG28HfX1D+duZUj4SMYsrHHniaVopuEtaMG ZWEdAUTC8ItTNEv8PVKtqighKVninOY9ZzXOUV2dF/VuSmYiQC75dve/VbLk16PvLz1d 9t6yjJ4LGRukuLLLTWWfkY/3CEICd8jtLYT0twPRtYPuAP6rFclFXWGfux3SDPfPb5vs GLpKxN/eitWOSHKAPlDKUCwAUTCOyxOC673+kbzS+pvoNJfPOCD2Bl4/HJTMxkOdsTCu pVvGc0eu8ZGOhSmaSK4W2/QYXHT72iyzxf8EMybANcx7sF9hAavfc30sE3xBRKeVqRfk Hr9g== X-Forwarded-Encrypted: i=1; AJvYcCWafBkBc8AyavKWG627buvlRcH6KYTKqv81UoVtvMF7TeeLmX82BUL3HdxzSfadstFnxOLZlG67oV4mG/BjGYktnk2mensEp9TLxGRh X-Gm-Message-State: AOJu0YzT0Gq6C0gI156XzS7GmowOrCMn4OwxeWXBTmE0HwM6OsUjPz/y gWGHPWzk7UsPPIFlhR5vloqx1kk/PyX67lCyVA3w7kdL/6B1q3tt8+pdAiCfh4c/8EpQlgAXZk8 FTjd2MsJdH0ULVtmcFxm557k6hlYWnQ== X-Google-Smtp-Source: AGHT+IE7ynqkbHV+q6whGOvR11/74PWMl8nNOPgSQSUBuFhQa7X4djYmU/EOfUpYJWodMb+ngJNB+LeP8l2WuyhHn8M= X-Received: by 2002:a05:6512:10d5:b0:52c:e402:4dc1 with SMTP id 2adb3069b0e04-52ee543da79mr6358034e87.55.1721408407492; Fri, 19 Jul 2024 10:00:07 -0700 (PDT) MIME-Version: 1.0 References: <04f4277e5ed4046773e46837110bed1381a2583f.camel@cybertec.at> <5468641ad821dad7aa3b2d65bf843146443a1b68.camel@cybertec.at> In-Reply-To: From: Robert Haas Date: Fri, 19 Jul 2024 12:59:56 -0400 Message-ID: Subject: Re: Incremental backup from a streaming replication standby fails To: David Steele Cc: Laurenz Albe , pgsql-hackers@postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Jul 19, 2024 at 11:32=E2=80=AFAM David Steele = wrote: > I think it would be enough just to add a hint such as: > > HINT: this is possible when making a standby backup with little or no > activity. That could work (with "this" capitalized). > My guess is in production environments this will be uncommon. I think so too, but when it does happen, confusion may be common. > Having said that, I think it would be better if it worked even if it > does produce an empty backup. An empty backup wastes some disk space but > if it produces less friction and saves an admin having to intervene then > it is probably worth it. I don't immediately see how to do that in a > reliable way, though, and in any case it seems like something to > consider for PG18. Yeah, I'm pretty reluctant to weaken the sanity checks here, at least in the short term. Note that what the check is actually complaining about is that the previous backup thinks that the WAL it needs to replay to reach consistency ends after the start of the current backup. Even in this scenario, I'm not positive that everything would be OK if we let the backup proceed, and it's easy to think of scenarios where it definitely isn't. Plus, it's not quite clear how to distinguish the cases where it's OK from the cases where it isn't. --=20 Robert Haas EDB: http://www.enterprisedb.com