Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wT3nt-000Hov-15 for pgsql-hackers@arkaria.postgresql.org; Fri, 29 May 2026 20:27:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wT3nq-004QFS-2F for pgsql-hackers@arkaria.postgresql.org; Fri, 29 May 2026 20:27:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wT3nq-004QFK-0y for pgsql-hackers@lists.postgresql.org; Fri, 29 May 2026 20:27:34 +0000 Received: from relay1-d.mail.gandi.net ([2001:4b98:dc4:8::221]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wT3nm-00000000CSf-0m4A for pgsql-hackers@lists.postgresql.org; Fri, 29 May 2026 20:27:34 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id B74233EEDB; Fri, 29 May 2026 20:27:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vondra.me; s=gm1; t=1780086443; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SNEaeq84VGtC8Xzk7XqtPcS8MpAZdQXI79IJndcuXAk=; b=KjIJHZwdkPzPdsCfSuh7z+ll1m6cU330ryRLEuqeHUKicjQohsmzSjIgEe2jB8JRa0LvIx h9298B9Aq8J2ynJiMIaryssnYHBKc2I5MHhCAa44BSUMiOdouqaD2XB/9eJ7Kklqrejww/ L5Np9thpkyE43s+E5Qdzw3z0oByFBez8r13gcHUSRRrhD51gIJn3QNgnFBP/yGEgB0JTQp e8FN0OsoeFpHI787atp4TVbbj3j230xolwKw/h0zU5cCFVN6Ceqam//K+Zbg0syju/Q1Ce v/rS/C8lB0q2Ozi/PrVaJF20baMVcrM2qm6JhCo2/6juaWPf/l5NAZxNBsaW1A== Message-ID: Date: Fri, 29 May 2026 22:27:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Changing the state of data checksums in a running cluster To: Daniel Gustafsson Cc: SATYANARAYANA NARLAPURAM , Ayush Tiwari , PostgreSQL Hackers , Heikki Linnakangas , Andres Freund , Bernd Helmle , Michael Paquier , Michael Banck References: <7357A519-3391-4F07-BC69-5C9C2B120792@yesql.se> <17BD06EB-3741-4921-AF60-6575FB4784ED@yesql.se> <9197F930-DDEB-4CAC-82A2-16FEC715CCE8@yesql.se> <6011EEE0-2D34-4A63-8B88-2437173486FE@yesql.se> <525E0691-FDAD-4194-9228-592A2DB96749@yesql.se> <9e1331e1-93a0-4e27-934a-17b89342be4d@vondra.me> <538e820b-db2a-4f53-ba24-c354c72fc1a9@vondra.me> Content-Language: en-US From: Tomas Vondra In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-GND-Sasl: tomas@vondra.me X-GND-Cause: dmFkZTGWDETl0fFbC11WWIpFTXQHxFoeqvWecesAlFuZR/vLx+ip0QRl3DPoV3XXcBCnHyJ6rZbzfZPOIc/ijGq22jARj82E8L8JGSvCawXPOH9Tz+4Hn2iqCzCe+iJlnyH2nljuKK7cTou2on1p3VCclyKK/f9N4irtYiir2vOoYHQFjW5uDbOsErJo0SCGI59kDR1Ujw32bks/B660C5RCkQwSUKgyXOlKFj8oQSSC/2yC0FRJFb/Vi+Ck+rMTI78AjSxEjBNmlkeSO9eb9vvYIgB1DTHzscObVMsQNLBCIls4QlfBu2dA+Ba1nv/3MAZ6wQNkByrxx/UMZdkGtkDejRjRSH6aBxxK2YLul01693cSPbuo5sM9KyQltGbGhjDfFW4UMjlEUPjJ+wYWoIVvPmE0SbrdubRO3P5QQjJmj4PCluNFj5HCR+gasGP3QK9qeoNLVv+0dXBfeRFTWbPCvlhzACvx0dk9V4BiaFBp/WslA0dXG1xeKz7sSxoP6L6ha9KemMXtSN1HanGFadnUAtKEs/QTh13FXChi+ZL1BagNPMOwrTS35SMuOWeD02WdWxCg/INwHkX0dRPur2NZtaMMqolfiqFiNYG2GfNBniSO+BQIe25BrsIyQqfQw9czZjtlPYJuAzjfqCzuLrEPu3AmAdujaoZ6Af3E4DXahxGxpg X-GND-State: clean X-GND-Score: -100 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 5/29/26 22:08, Daniel Gustafsson wrote: >> On 28 May 2026, at 13:51, Tomas Vondra wrote: >> >> On 5/28/26 13:28, Daniel Gustafsson wrote: >>>> On 26 May 2026, at 20:12, Tomas Vondra wrote: >>> >>>> I suppose this means we should not be updating the checksum state >>>> without emitting the barrier? I think all other places do that. >>> >>> Good catch, it's indeed a bug, any state change must emit a procsignalbarrier >>> to maintain cluster consistency. I ended up writing a test for this very case >>> as well. >> >> Good. > > I've pushed this now, along with your other findings, ahead of the beta1 > deadline, buildfarm seems happy so far. > Thanks! >>>> I still don't understand why this needs DELAY_CHKPT_START ... >>> >>> Having stared at this for some time, and going over old threads, I think this >>> is a mistake. AFAICT though it cannot cause any error, so I'd lean towards >>> erring on the safe side by leaving as is and looking at removing in 20. What >>> do you think? >>> >> >> I'd probably try to fix this for 19, otherwise it may be confusing >> people looking at the code in the future. We're still months from 19 >> getting released. Ofc, maybe I'm underestimating the risk. > > You're probably right. Once beta1 is out I'll work on getting this fixed. > +1 regards -- Tomas Vondra