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 1ngsbH-0007Ah-TG for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Apr 2022 18:29:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ngsbG-000388-DQ for pgsql-hackers@arkaria.postgresql.org; Tue, 19 Apr 2022 18:29:18 +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 1ngsbG-00037Q-3x for pgsql-hackers@lists.postgresql.org; Tue, 19 Apr 2022 18:29:18 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ngsbA-000804-J2 for pgsql-hackers@lists.postgresql.org; Tue, 19 Apr 2022 18:29:16 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 23JIT68G2571202; Tue, 19 Apr 2022 14:29:07 -0400 From: Tom Lane To: Alvaro Herrera cc: Andres Freund , pgsql-hackers@lists.postgresql.org, Noah Misch , Peter Geoghegan , David Rowley , Amit Kapila , Masahiko Sawada Subject: Re: Intermittent buildfarm failures on wrasse In-reply-to: <202204191637.eldwa2exvguw@alvherre.pgsql> References: <202204191637.eldwa2exvguw@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Tue, 19 Apr 2022 18:37:13 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2571200.1650392946.1@sss.pgh.pa.us> Date: Tue, 19 Apr 2022 14:29:06 -0400 Message-ID: <2571201.1650392946@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alvaro Herrera writes: > On 2022-Apr-15, Tom Lane wrote: >> Here's a WIP patch for that. The only exciting thing in it is that >> because of some undocumented cowboy programming in walsender.c, the >> Assert((proc->statusFlags & (~PROC_COPYABLE_FLAGS)) == 0); >> in ProcArrayInstallRestoredXmin fires unless we skip that. > Hmm, maybe a better use of that define is to use to select which flags > to copy, rather than to ensure we they are the only ones set. What > about this? Yeah, I thought about that too, but figured that the author probably had a reason for writing the assertion the way it was. If we want to redefine PROC_COPYABLE_FLAGS as "flags associated with xmin", that's fine by me. But I'd suggest that both the name of the macro and the comment for it in proc.h should be revised to match that definition. Another point is that as you've coded it, the code doesn't so much copy those flags as union them with whatever the recipient had, which seems wrong. I could go with either Assert(!(MyProc->statusFlags & PROC_XMIN_FLAGS)); MyProc->statusFlags |= (proc->statusFlags & PROC_XMIN_FLAGS); or MyProc->statusFlags = (MyProc->statusFlags & ~PROC_XMIN_FLAGS) | (proc->statusFlags & PROC_XMIN_FLAGS); Perhaps the latter is more future-proof. regards, tom lane