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 1nMZ6M-0001Qh-Mv for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Feb 2022 17:37:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nMZ6L-00073u-Hb for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Feb 2022 17:37:25 +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 1nMZ6L-00073l-6G for pgsql-hackers@lists.postgresql.org; Tue, 22 Feb 2022 17:37:25 +0000 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nMZ6E-0005rz-1N for pgsql-hackers@postgresql.org; Tue, 22 Feb 2022 17:37:24 +0000 Received: by mail-pg1-x534.google.com with SMTP id z4so17596447pgh.12 for ; Tue, 22 Feb 2022 09:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=us5TglpdjWhcv+0Lttp4N+kpxwjGrIpPZYbR2iJK7BE=; b=mcyqScVPzOi1pUCdqr9c06JnJzN/hX2Tgt9D1QPkfaxRupRvb1hdBfWsOba1yhfL0E YVBaGlPPVFUu/QM25gOYOxWaNbOVNrDWoZ1TOEmyr0Ye8ne3ydFr6P4O3UE9QaeaqnFJ WZgvt9Y69g/wUPLKlu6ljil+pjZeP4dpP/GBLNiSuHzEuykDuh0QFaZ1TV3ZDcvAEAZF QwhBl1m6tHe5UYlYDeJffEcmPYOOsHRfD37Ads9iTxM6EOCtO+A6LFAUxwrzWa4lyUEj p3S0yN558LFaIyXtwawEAnxqTBoFGzNc7gFmx9YoASFzDG7bUPKqta07fvutr+3gHL9K WFMg== 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:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=us5TglpdjWhcv+0Lttp4N+kpxwjGrIpPZYbR2iJK7BE=; b=7Fw7JSL/wySRb5C+3Dg3wP8v/esBmgBOTca18TnFhi7N2xinuKVKjhCtv7ptNGufdH HlQFEdJshkId0hZyF/6RGeQ4UE3TCejcpn9P19hVfhZDxQ5Yb2bfMfD1VyYYrlTbyM2D nl6Mm7KlWZpLCdyL+EsyKhkiYAbpka1ZYZlExQiDiJIaLawFrwfH4Se1tFVttinslE3R LjzY4hy6sNdqLkiLpyXWmYVbXtdgf/KeXx5Ck+D90q++KNuryPZ19fhqdcQ10IjXtZLv EtC8uQGzCwA971+74aQEoFQ4mbvTMc06PA3RC1wKZ7qx/EVHWngQhQIfGdSlG4513R5L vhLw== X-Gm-Message-State: AOAM5305XXJsIwJa2/xcDfTTK37o0943NASuu9tGbyyubtW8PEQ2wCDQ xaETYNT8gfmAPBOrcdbZp0XtmbbnC84= X-Google-Smtp-Source: ABdhPJyXZAS3w1pULg/VvuxWaHKaIizzQNECN7SqEK9c5C4lxdUZM3P9SttDtWlnyaU02dtnbFV4pw== X-Received: by 2002:a63:4509:0:b0:372:8235:b060 with SMTP id s9-20020a634509000000b003728235b060mr20639845pga.92.1645551434798; Tue, 22 Feb 2022 09:37:14 -0800 (PST) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id lp10sm90201pjb.44.2022.02.22.09.37.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Feb 2022 09:37:14 -0800 (PST) Date: Tue, 22 Feb 2022 09:37:11 -0800 From: Nathan Bossart To: pgsql-hackers@postgresql.org Subject: Re: remove more archiving overhead Message-ID: <20220222173711.GA3852671@nathanxps13> References: <20220222011948.GA3850532@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220222011948.GA3850532@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Feb 21, 2022 at 05:19:48PM -0800, Nathan Bossart wrote: > I also spent some time investigating whether durably renaming the archive > status files was even necessary. In theory, it shouldn't be. If a crash > happens before the rename is persisted, we might try to re-archive files, > but your archive_command/archive_library should handle that. If the file > was already recycled or removed, the archiver will skip it (thanks to > 6d8727f). But when digging further, I found that WAL file recyling uses > durable_rename_excl(), which has the following note: > > * Note that a crash in an unfortunate moment can leave you with two links to > * the target file. > > IIUC this means that in theory, a crash at an unfortunate moment could > leave you with a .ready file, the file to archive, and another link to that > file with a "future" WAL filename. If you re-archive the file after it has > been reused, you could end up with corrupt WAL archives. I think this > might already be possible today. Syncing the directory after every rename > probably reduces the likelihood quite substantially, but if > RemoveOldXlogFiles() quickly picks up the .done file and attempts > recycling before durable_rename() calls fsync() on the directory, > presumably the same problem could occur. In my testing, I found that when I killed the server just before unlink() during WAL recyling, I ended up with links to the same file in pg_wal after restarting. My latest test produced links to the same file for the current WAL file and the next one. Maybe WAL recyling should use durable_rename() instead of durable_rename_excl(). -- Nathan Bossart Amazon Web Services: https://aws.amazon.com