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 1neJMs-0005wA-NS for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Apr 2022 16:27:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1neJMr-0005Q9-1o for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Apr 2022 16:27:49 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neJMq-0005Pq-MI for pgsql-hackers@lists.postgresql.org; Tue, 12 Apr 2022 16:27:48 +0000 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1neJMo-0006rC-9y for pgsql-hackers@postgresql.org; Tue, 12 Apr 2022 16:27:47 +0000 Received: by mail-pf1-x430.google.com with SMTP id s2so17955321pfh.6 for ; Tue, 12 Apr 2022 09:27:46 -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=bqMW5y/gL3nIdyf7x0Z1/Q+QYiO5DASN6z/ODcIZ0qY=; b=V7xEGL8zPGbXR2oDNTDgZ42P7sI/wDd98VKVUZA+eIfRSOTm8b3nSI6eoPGmp8iTAP GelRk9fnBNQ3yeXaRmShHUqMzuya/H4WweiuW2aXGXkFn9e8AlqB3WLWBnAFEsRB5YVw gFdyuI512QHpWDfEr4/uHgJ1fV6j3GgS+O9DmpKIcfqsFefaVK22TkBU/lxG23qvuhFC dlhH1rIVmPcarzGP72Iz+YolAqn9S+m5JS55ITaYHFg7B1WjMXdjAsV0mROgMRy3AbVV 8TiQlgBo0lyBtlnBvcXh0xc0haZ6h4ugNB6aPGmP/w0E6tEhgWOcCo7rS3dBKkpndHEn RhOQ== 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=bqMW5y/gL3nIdyf7x0Z1/Q+QYiO5DASN6z/ODcIZ0qY=; b=lsIwPvm0jf8k6zNjH9ytAGeeYKdoOpRy5nX38wpwXRVKc5mUBmIX1gYQa3tXHqtdAQ NhuBT2RtzVqxjq0RDCnlXNaliBhYNY4ktg4PvLxzFndtLrGwpHD7zssoB8vzovRlkXhU +yIhu1mR0Z7V9vA7e73XHwTSa9iStT7MS+ajHOIlvo+j8KLIu0DCsZ5SqaG+HynoUCa8 aMz3ousVGfJmBtTzkBoAnIzKWs2ZTtd6w6At7A/LfL91tgk9yoATIRM6YrhWVtKw6ox8 dxOzrSMeS/0TroI6bpCShAme2AjziQPxPTnXa9KmF1fcUMOX9itvCRg+gNWkK2gGDqcf /LsQ== X-Gm-Message-State: AOAM531FCd55Ry+cN2UObNqRaSyfPV7Q8FXNHQzAUlcEmeyt4t13o0lt jd3tYLkVo8GwBYp9rExB6/M= X-Google-Smtp-Source: ABdhPJxnmj6PHv1DUWgnxKBTo74H22+ZlDwo+y+L9M7REv8D4h2YTsV2FAd2OCKidZOPqrU/C+tdUQ== X-Received: by 2002:a05:6a00:1a0a:b0:4fc:d6c5:f3f1 with SMTP id g10-20020a056a001a0a00b004fcd6c5f3f1mr39223357pfv.45.1649780865367; Tue, 12 Apr 2022 09:27:45 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id b77-20020a621b50000000b00505fda28908sm3253260pfb.97.2022.04.12.09.27.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 09:27:44 -0700 (PDT) Date: Tue, 12 Apr 2022 09:27:42 -0700 From: Nathan Bossart To: Kyotaro Horiguchi Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, pgsql-hackers@postgresql.org Subject: Re: avoid multiple hard links to same WAL file after a crash Message-ID: <20220412162742.GB2062175@nathanxps13> References: <289699.1649694527@sss.pgh.pa.us> <20220411165257.GB1915258@nathanxps13> <20220412.154631.417529439388886590.horikyota.ntt@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220412.154631.417529439388886590.horikyota.ntt@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Apr 12, 2022 at 03:46:31PM +0900, Kyotaro Horiguchi wrote: > At Mon, 11 Apr 2022 09:52:57 -0700, Nathan Bossart wrote in >> I traced this back a while ago. I believe the link() was first added in >> November 2000 as part of f0e37a8. This even predates WAL recycling, which >> was added in July 2001 as part of 7d4d5c0. > > f0e37a8 lacks discussion.. It introduced the CHECKPOINT command from > somwhere out of the ML.. This patch changed XLogFileInit to > supportusing existent files so that XLogWrite can use the new segment > provided by checkpoint and still allow XLogWrite to create a new > segment by itself. Yeah, I've been unable to find any discussion besides a brief reference to adding checkpointing [0]. [0] https://postgr.es/m/8F4C99C66D04D4118F580090272A7A23018D85%40sectorbase1.sectorbase.com -- Nathan Bossart Amazon Web Services: https://aws.amazon.com