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.94.2) (envelope-from ) id 1t7RAz-001tVF-Ns for pgsql-committers@arkaria.postgresql.org; Sun, 03 Nov 2024 03:21:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t7RAx-009rHx-RP for pgsql-committers@arkaria.postgresql.org; Sun, 03 Nov 2024 03:21:16 +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.94.2) (envelope-from ) id 1t7RAx-009rHo-Jb for pgsql-committers@lists.postgresql.org; Sun, 03 Nov 2024 03:21:15 +0000 Received: from mail-pf1-x42b.google.com ([2607:f8b0:4864:20::42b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t7RAr-004SHx-CV for pgsql-committers@lists.postgresql.org; Sun, 03 Nov 2024 03:21:15 +0000 Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-72097a5ca74so2927139b3a.3 for ; Sat, 02 Nov 2024 20:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1730604067; x=1731208867; darn=lists.postgresql.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=kkerW9GWEHejuWunIGqjan7RMvlY202+lVKog79LeZY=; b=OTcEmnwjTgOWw5HhRVraYYMDVKVPOnbkwykf3xCfaAgpLg1en30A/Ly8V/Ugmia/fH nOyAagVohuVLxUh46U0Vu7WpBC1mEDh37ePXPefS8bg/7q+cp7h0eKgUvzgI6axo8scM 6TgDTsvUBrqutLsoiLKDJLYCP0FcNNb2AAW6I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730604067; x=1731208867; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=kkerW9GWEHejuWunIGqjan7RMvlY202+lVKog79LeZY=; b=Ugl942WvwYQk/gZS+J6U5JO+PEGTtY0gkDHLarJSDhVF6ctnGRnkJIPuKocTzH3Coh o1rLjRzKRZl7a5PuJ06DFWRnExYx2wtDORR++SL+96uvDnzFO7Fd9nK55VPgG8vy1Ekd FD5biwAHiQjFLI8mik6X41sgGxtNJ2kxXYpmYaOd7zp1QMUO6Qun3N3Wd33hMPh4xqpp VhVI46rS3gI799Q+MaLb1ZT2zRw75hnBtKjWSdnK2IZc3MGN57N798glXQ6foF/m5GsX iRTOg7LFmUJ71UoQCVvg+L769Xn7f/xZS3hL/MBg5vWbOhuVqI7Fzf2I7X+WZ4SVs0pz K40A== X-Gm-Message-State: AOJu0YzACmFrDSHsY2THsvcCZRftQGIldGNDvOzqMK4f938Z0kqWPFH7 vbxYVLuIJvKv2AMh9vwr7Qy70y9CQGo+38vwbPIsRDmOgFni5swLRi4cqyJ38g== X-Google-Smtp-Source: AGHT+IGqp8RWW/jNVAY7WGYDvfx4BnN/2MZpEUD9x/3wtKhInSqh34n0YOvB+cAwJXBFpzsOrw4dYg== X-Received: by 2002:a05:6a21:3a82:b0:1d9:dd4a:4381 with SMTP id adf61e73a8af0-1dba5323990mr11684271637.23.1730604067080; Sat, 02 Nov 2024 20:21:07 -0700 (PDT) Received: from google.com ([2600:1702:a20:5750::48]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-720bc2c5493sm4914937b3a.115.2024.11.02.20.21.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Nov 2024 20:21:06 -0700 (PDT) Date: Sat, 2 Nov 2024 20:21:04 -0700 From: Noah Misch To: Tom Lane Cc: pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Move I/O before the index_update_stats() buffer lock region. Message-ID: <20241103032104.bf.nmisch@google.com> References: <2317336.1730601176@sss.pgh.pa.us> <20241103031027.09.nmisch@google.com> <2322263.1730603637@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2322263.1730603637@sss.pgh.pa.us> User-Agent: Mutt/2.2.12 (2023-09-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Nov 02, 2024 at 11:13:57PM -0400, Tom Lane wrote: > Noah Misch writes: > > On Sat, Nov 02, 2024 at 10:32:56PM -0400, Tom Lane wrote: > >> In branches before 17, this commit is causing some compilers > >> to complain: > > > Hopefully now the code won't fool any compiler. > > I saw your commit, and I'm content with it, but did you figure > out why the warning only appears pre-17? (At least, that's > what I got locally.) Nope. The principles behind the variable's lifecycle didn't change. Here's the function's diff between v16 and v17. (Same diff all the way from v12 to v17.) Perhaps the reference to non-local variable IsBinaryUpgrade changed the compiler's deductive capability, somehow. @@ -2836,7 +2806,11 @@ index_update_stats(Relation rel, if (reltuples == 0 && rel->rd_rel->reltuples < 0) reltuples = -1; - update_stats = reltuples >= 0; + /* + * Don't update statistics during binary upgrade, because the indexes are + * created before the data is moved into place. + */ + update_stats = reltuples >= 0 && !IsBinaryUpgrade; /* * Finish I/O and visibility map buffer locks before