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 1oJ8cY-0003Ou-Gj for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Aug 2022 07:16:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oJ8cW-0005XX-E8 for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Aug 2022 07:16:44 +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 1oJ8cR-0005U7-Lo for pgsql-hackers@lists.postgresql.org; Wed, 03 Aug 2022 07:16:44 +0000 Received: from mail-qt1-x82e.google.com ([2607:f8b0:4864:20::82e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oJ8cB-00025y-Sa for pgsql-hackers@postgresql.org; Wed, 03 Aug 2022 07:16:38 +0000 Received: by mail-qt1-x82e.google.com with SMTP id z3so899381qtv.5 for ; Wed, 03 Aug 2022 00:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc; bh=Stzj4nvYSXVflWIHD6BmP/v4vd/ne9ngPiDHtF9KX6s=; b=JgGH0jnyR8Wr1NF3Cl3nHt+EccBElk20WmcjPmhQ2GQWNQDES5u/ULP9PSsuk6HBu7 eA8JaGdBenABDsc5wFS+2Z8XRxvDhu0dVe88o/ovQ0PkylmIxbYjLg8QpH80U4GlXDWk wZBSIeDxLZ0sp4FdS/sbwkKmC5qHPEg1RdudY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=Stzj4nvYSXVflWIHD6BmP/v4vd/ne9ngPiDHtF9KX6s=; b=OfoSPighaplfoRiprI5vqn7diz+T1r9dxdtIN7IcNmL7naIObZf+O1jS8U5LA2BrBU r4Cjst/ZGILUce0d5BjORaYGjmUv1RndYRLWafgmKB7YrwUyGia+BpL3tLQlkZkFOuep NehrVqwPDhDryNKcg+YJ5KTyWSPRktWv7zvaolkTyFiCoTdmojbBnrK7FUlwQkFMaxVT m0A4XkGYCBpn/NYeKfVPU+rDvufH5bjqrWMdydLBjiJ4Ic8Yi/mXbfLtOIP7uDIjeBzL fOV3AgBa5VtALQdcY24mczCn6N058PGkVfwEphrtmX52o0xPauQd1cuqYteTmHJ5vBo/ V0yg== X-Gm-Message-State: AJIora/GAOPB9iGk03pHsOPrPG9NfIb0WshAWE7295dxqJsGo97DaISK Pelv9nm6QqdTDJJY74FqFK3MVA== X-Google-Smtp-Source: AGRyM1sqv1C7HfEcgp9gdLUuMDV4peKb6FESG8cFYfKysaZmAmMhtLYoeEQVJCSHWAcpG/LB9Zlanw== X-Received: by 2002:ac8:5f48:0:b0:31f:c78:e596 with SMTP id y8-20020ac85f48000000b0031f0c78e596mr21133811qta.169.1659510981518; Wed, 03 Aug 2022 00:16:21 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id az20-20020a05620a171400b006a5d2eb58b2sm12172090qkb.33.2022.08.03.00.16.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2022 00:16:20 -0700 (PDT) Date: Wed, 3 Aug 2022 00:16:17 -0700 From: Noah Misch To: Nathan Bossart Cc: David Steele , Kyotaro Horiguchi , robertmhaas@gmail.com, masao.fujii@oss.nttdata.com, pgsql-hackers@postgresql.org Subject: Re: remove more archiving overhead Message-ID: <20220803071617.GA3817792@rfd.leadboat.com> References: <20220707182251.GA2255242@nathanxps13> <20220707220716.GA2258527@nathanxps13> <20220708.105652.1551158050191356887.horikyota.ntt@gmail.com> <44dbf5e4-8eec-da56-daba-755128b3723e@pgmasters.net> <20220708165450.GA2356733@nathanxps13> <20220731065156.GA3694276@rfd.leadboat.com> <20220802050219.GA475090@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220802050219.GA475090@nathanxps13> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Aug 01, 2022 at 10:02:19PM -0700, Nathan Bossart wrote: > On Sat, Jul 30, 2022 at 11:51:56PM -0700, Noah Misch wrote: > > Inviting the administrator to resolve things is more dangerous than just > > returning true. I recommend making this text more opinionated and simpler: > > libraries must return true. Alternately, if some library has found a good > > reason to return false, this paragraph could give the reason. I don't know of > > such a reason, though. > > Your suggestion seems reasonable to me. I've attached a small patch. > --- a/doc/src/sgml/backup.sgml > +++ b/doc/src/sgml/backup.sgml > @@ -691,11 +691,9 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/0 > system crashes before the server makes a durable record of archival success, > the server will attempt to archive the file again after restarting (provided > archiving is still enabled). When an archive library encounters a > - pre-existing file, it may return true if the WAL file has > + pre-existing file, it should return true if the WAL file has > identical contents to the pre-existing archive and the pre-existing archive > - is fully persisted to storage. Alternatively, the archive library may > - return false anytime a pre-existing file is encountered, > - but this will require manual action by an administrator to resolve. If a > + is fully persisted to storage. If a > pre-existing file contains different contents than the WAL file being > archived, the archive library must return > false. Works for me. Thanks.