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 1ncr9Z-0003XX-WE for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Apr 2022 16:08:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ncr9Y-0004L4-Lp for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Apr 2022 16:08:04 +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 1ncr9Y-0004Kv-Ab for pgsql-hackers@lists.postgresql.org; Fri, 08 Apr 2022 16:08:04 +0000 Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ncr9V-0000Fx-6x for pgsql-hackers@postgresql.org; Fri, 08 Apr 2022 16:08:03 +0000 Received: by mail-pf1-x432.google.com with SMTP id p8so8739787pfh.8 for ; Fri, 08 Apr 2022 09:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=L4PsezIx6+uVvOVV3XmIcWvLGAYeDESuuIZq5XFGw0s=; b=F5aoXI4aRsyO8kPBpDPjPtRcyu3LXbc9KQK5EqGkoir41UBE5hxrwJBwuMD1n5HrGx gzg9N8LdnSwgpNKOZF0hVFSpepRoFNiH/Z8IKcQ5iZ7x7br5nmaGb0GN7NIpD76fCnuc cRP39Otrcwykj7uWkIEnuMrBtg1NLsK3iBm77nd4KlkHNNg4PBidfmFFQuWOaj2Aa64L flGu3Q9zRTBqLa0ffpkMk3lZvxlaMiT/WiwmZZupH4x9IJY3SxfF1w6H+/Z6EtN13uhE us/Npa2G+y6dwbWhXQ6LUech+KHjV0UdbJpAT+UBdB8UyV2thjJgq0b6uEWBBqCNopDi HCtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=L4PsezIx6+uVvOVV3XmIcWvLGAYeDESuuIZq5XFGw0s=; b=56/05Oq3Rr+W1MzoiEHKHT0a8OGfYgxyKGmYolSrwvf8/0vDtV1+Kx9Z2vcesRLrEx a1biw4GzRJyrCvJZsmCjYumHIAVpXbY6xBjJ57CH0/GP8csdZdIAT6gonfjYT5AVtWxx KelF/74zeq6b4rDqqLmA9xUtBgUCY+XwaZY+4iCUBhVtf4XCDQ/ONCcm06V8i+gGcDC0 78RwItaeYkBjwrckG5FVch2WSoyXr1GADDTO933v9eDrUhwD/ZQ1nGO2kHtkKmG2PrYj pMRrmAJyjUDaqqSW/rnTwHBYAhwu91kdE0Ue4JzTXFvvM7VnzjWhnSUSKDdj+mc1OWAt s+4g== X-Gm-Message-State: AOAM533tgLKZ8MDmV9SKTy5fwm5SY6l2SZtnDj9w35BRXK0LtyxZN698 SlSr5ohSaEjckcW3vt8pjbI= X-Google-Smtp-Source: ABdhPJzSAZM58saNVm77oTZ7TSiRbRixKPUGZKLpkpTlpnnlwJgdATq8o/ubjhq3aEpWaXS66YjOvg== X-Received: by 2002:a62:5fc4:0:b0:4fa:7a4b:3853 with SMTP id t187-20020a625fc4000000b004fa7a4b3853mr20418360pfb.77.1649434078274; Fri, 08 Apr 2022 09:07:58 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id h20-20020a056a001a5400b004fb1b4b010asm26986137pfv.162.2022.04.08.09.07.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Apr 2022 09:07:57 -0700 (PDT) Date: Fri, 8 Apr 2022 09:07:56 -0700 From: Nathan Bossart To: Robert Haas Cc: Kyotaro Horiguchi , "pgsql-hackers@postgresql.org" Subject: Re: remove more archiving overhead Message-ID: <20220408160756.GA1409034@nathanxps13> References: <20220222011948.GA3850532@nathanxps13> <20220222173711.GA3852671@nathanxps13> <20220222195229.GA42988@nathanxps13> <20220224.141349.1809640551882183816.horikyota.ntt@gmail.com> <20220224175553.GA660690@nathanxps13> <20220407222327.GA1363808@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Apr 08, 2022 at 10:20:27AM -0400, Robert Haas wrote: > On Thu, Apr 7, 2022 at 6:23 PM Nathan Bossart wrote: >> On Thu, Feb 24, 2022 at 09:55:53AM -0800, Nathan Bossart wrote: >> > Yes. I found that a crash at an unfortunate moment can produce multiple >> > links to the same file in pg_wal, which seemed bad independent of archival. >> > By fixing that (i.e., switching from durable_rename_excl() to >> > durable_rename()), we not only avoid this problem, but we also avoid trying >> > to archive a file the server is concurrently writing. Then, after a crash, >> > the WAL file to archive should either not exist (which is handled by the >> > archiver) or contain the same contents as any preexisting archives. >> >> I moved the fix for this to a new thread [0] since I think it should be >> back-patched. I've attached a new patch that only contains the part >> related to reducing archiving overhead. > > While we're now after the feature freeze and thus this will need to > wait for v16, it looks like a reasonable change to me. Dang, just missed it. Thanks for taking a look. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com