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 1njQ0f-000450-1x for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Apr 2022 18:34:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1njQ0d-0004il-G5 for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Apr 2022 18:33:59 +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 1njQ0d-0004ib-4m for pgsql-hackers@lists.postgresql.org; Tue, 26 Apr 2022 18:33:59 +0000 Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1njQ0W-0001Cs-H4 for pgsql-hackers@lists.postgresql.org; Tue, 26 Apr 2022 18:33:58 +0000 Received: by mail-pg1-x52a.google.com with SMTP id k14so16794165pga.0 for ; Tue, 26 Apr 2022 11:33:52 -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=D7lvkvj9vaxogRxptnzX5PqYI3LoBvTZRDywbdHJA/o=; b=nFfbFzTlojV0Z4xELk5WiKs2CIRO5zSxUKqvwkXL2q/a2mldcImXshif2Y3JFZxqpI FdjzRjM8FXygG3Ax7UAMmH6mcm/ISRIV0df3VEZMvvT2y6AAB/ggtOl6v6vRwlSi1CNp GYK3QyMAMpnbNFREMUcZn60jlXOce0zjYacG4WdBXPK5yjuImvekFvHHyp6Pd8JX3mDX wPgXUIInZUpQkKFvwBrg2H5XkeeBOX3hFAYfmj/Kv3dnyeBWx98FlbqPh4l7VqBwLQmf 83Ncv2y6pBZ0MsJmQge5yP2TS3PM10yob1gM7p02CbgcxETookdNkESB2jFVGBPiH+6P Eawg== 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=D7lvkvj9vaxogRxptnzX5PqYI3LoBvTZRDywbdHJA/o=; b=tP+wf4BawLcGaKmPWJL08V/HXD/S59Vq0FM02pv5G4Yz2paDaGPthSWL0X/VeEzmlg sx/1kjO3EGrNmntuj1OyT4JCF+wLMATh43h4iUG96ejhvYeSlNgw/KSqLcA0o29zB727 1oeL/ew/Cip6OQSClpH2h5jqinsGuljL/rtUyvEMXbctPWk10LFfXwMw4wikrd2cRMi2 uUvNWIBGVNc257hPVbQGWYAD2aOxs+GPUbv3+KfcOodwxQHXuZbPOVRAoITTFdzwOAwb 46HAvOPgHFfSle/hrIUzP0DSricdQps10xSIfKNNgWMruF1lfHcH5jbkgRIin3joWiZg a3Xw== X-Gm-Message-State: AOAM530ubMDrwhFBGBSQGfzXU/rsSou3D4y2WPaJmFX9OV14MJ6Hv2FQ vw6izCdtGd5RwuqyZb/KMdk= X-Google-Smtp-Source: ABdhPJwUp+9EO0UxGALCxlVa8GEUdTUoKGy9ws7Aat1JciGKncTmjPPhvelTWK1Yz1U2X7irKCLjgg== X-Received: by 2002:a05:6a02:18b:b0:399:365e:f09c with SMTP id bj11-20020a056a02018b00b00399365ef09cmr21106222pgb.238.1650998031460; Tue, 26 Apr 2022 11:33:51 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id fa23-20020a17090af0d700b001bf31f7520csm3779975pjb.1.2022.04.26.11.33.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Apr 2022 11:33:50 -0700 (PDT) Date: Tue, 26 Apr 2022 11:33:49 -0700 From: Nathan Bossart To: Kyotaro Horiguchi Cc: pgsql-hackers@lists.postgresql.org, masao.fujii@oss.nttdata.com Subject: Re: Possible corruption by CreateRestartPoint at promotion Message-ID: <20220426183349.GA3002960@nathanxps13> References: <20220316.102444.2193181487576617583.horikyota.ntt@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220316.102444.2193181487576617583.horikyota.ntt@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Mar 16, 2022 at 10:24:44AM +0900, Kyotaro Horiguchi wrote: > While discussing on additional LSNs in checkpoint log message, > Fujii-san pointed out [2] that there is a case where > CreateRestartPoint leaves unrecoverable database when concurrent > promotion happens. That corruption is "fixed" by the next checkpoint > so it is not a severe corruption. I suspect we'll start seeing this problem more often once end-of-recovery checkpoints are removed [0]. Would you mind creating a commitfest entry for this thread? I didn't see one. > AFAICS since 9.5, no check(/restart)pionts won't run concurrently with > restartpoint [3]. So I propose to remove the code path as attached. Yeah, this "quick hack" has been around for some time (2de48a8), and I believe much has changed since then, so something like what you're proposing is probably the right thing to do. > /* Also update the info_lck-protected copy */ > SpinLockAcquire(&XLogCtl->info_lck); > - XLogCtl->RedoRecPtr = lastCheckPoint.redo; > + XLogCtl->RedoRecPtr = RedoRecPtr; > SpinLockRelease(&XLogCtl->info_lck); > > /* > @@ -6984,7 +6987,10 @@ CreateRestartPoint(int flags) > /* Update the process title */ > update_checkpoint_display(flags, true, false); > > - CheckPointGuts(lastCheckPoint.redo, flags); > + CheckPointGuts(RedoRecPtr, flags); I don't understand the purpose of these changes. Are these related to the fix, or is this just tidying up? [0] https://postgr.es/m/CA%2BTgmoY%2BSJLTjma4Hfn1sA7S6CZAgbihYd%3DKzO6srd7Ut%3DXVBQ%40mail.gmail.com -- Nathan Bossart Amazon Web Services: https://aws.amazon.com