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 1nKNQF-0002Ci-0q for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Feb 2022 16:44:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nKNQD-0001iq-4J for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Feb 2022 16:44:53 +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 1nKNQC-0001hy-PH for pgsql-hackers@lists.postgresql.org; Wed, 16 Feb 2022 16:44:52 +0000 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nKNQ6-0000OU-38 for pgsql-hackers@postgresql.org; Wed, 16 Feb 2022 16:44:51 +0000 Received: by mail-pj1-x1033.google.com with SMTP id v8-20020a17090a634800b001bb78857ccdso4639311pjs.1 for ; Wed, 16 Feb 2022 08:44:45 -0800 (PST) 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=849jfLJjC0RxgVIaaR32Hfiqegx2RqntzQndew46hN8=; b=WuuQGGKtIic+4Wm0lmrOsRsD49s47acycuJT98ZBZMtZYpAXMIUsAtIkwefRMqVVJC WbgiFrtGyePzEJ3bsjmqC+Q0dQq7X378OE3HIDWgbrMRxG6n9ZTiLXttW6Ka2M7vtZpn im0vmc74l7FYmJOL9+0TVRxXFVKY+12mA2Pr7GgJ034sEWky0kbloPNfyKcQmv6/Hs4m YnCl0SxEIlxOfdTe96myiQmJRE3/NGR9g6LV1a5crpdUaBfvT5xNo1JGsBQNpkGOYeye VDM9ZxoorN/hk0Lwa7YPAXwCsz/opecvQvCkTNbby3584S7J20MElw7EUEshHvrQ86Tm zsGQ== 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=849jfLJjC0RxgVIaaR32Hfiqegx2RqntzQndew46hN8=; b=iW4hGpeH8JUAWuHCysXILnf/3tJ4xmYpnaLgq0lD8jFtsK9GKwALN+lCOMtptFiEGo jq3rrlq0qte/nLawe8SyDhtvoQQxna/J4xpXuJQurUba1++W2o0k7c2rVaGoHHJtq6I+ wKbgsR1rRJImEEsoY5FpJwls3mHXIwSsCVytqCjW9f1w7VxHebwMG+uGlVMMcTwlw5R+ YUXH5rugrwJDIr8JzUnW/l5sbFjOlNeXKvBGSuFTk1Cn61gl1Zk86yE5NChGrOCntNMT DP1nhACwj5HjU6JQI/2YHCYk6IXu0jEUrmBy5CjEKgAqeuzEXEGzbp8lFaiT92ESvnTy UoSQ== X-Gm-Message-State: AOAM532bCUxpLxzGpFR/JfErD9xtvRARM/qd1xRuH9gKpAlIVgX5sYAL CIelrzVkdcnnCLgz4sgBz7k= X-Google-Smtp-Source: ABdhPJwKsx8Ig9ee02o5q+QTGFm80wL1UOI7t54BhAd+Koxas2tIDbF1UTBSWB/UMP4Z60mS9izVJQ== X-Received: by 2002:a17:90b:1a92:b0:1b9:8094:446b with SMTP id ng18-20020a17090b1a9200b001b98094446bmr2672004pjb.93.1645029884843; Wed, 16 Feb 2022 08:44:44 -0800 (PST) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id h16sm15940847pfh.40.2022.02.16.08.44.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Feb 2022 08:44:44 -0800 (PST) Date: Wed, 16 Feb 2022 08:44:42 -0800 From: Nathan Bossart To: Andres Freund Cc: Thomas Munro , pgsql-hackers Subject: Re: USE_BARRIER_SMGRRELEASE on Linux? Message-ID: <20220216164442.GA2935315@nathanxps13> References: <20220215235845.GA2665318@nathanxps13> <20220216045911.GA2791824@nathanxps13> <20220216050645.7u3nguccykpqaw7p@alap3.anarazel.de> <20220216061404.GA2813338@nathanxps13> <20220216065732.GA2932808@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220216065732.GA2932808@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Feb 15, 2022 at 10:57:32PM -0800, Nathan Bossart wrote: > On Tue, Feb 15, 2022 at 10:14:04PM -0800, Nathan Bossart wrote: >> It looks like register_unlink_segment() is called prior to the checkpoint, >> but the checkpointer is not calling RememberSyncRequest() until after >> SyncPreCheckpoint(). This means that the requests are registered with the >> next checkpoint cycle count, so they aren't processed until the next >> checkpoint. > > Calling AbsorbSyncRequests() before advancing the checkpoint cycle counter > seems to fix the issue. However, this requires moving SyncPreCheckpoint() > out of the critical section in CreateCheckPoint(). Patch attached. An alternative fix might be to call AbsorbSyncRequests() after increasing the ckpt_started counter in CheckpointerMain(). AFAICT there is a window just before checkpointing where new requests are registered for the checkpoint following the one about to begin. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com