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 1txErn-005HsV-NI for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Mar 2025 00:43:35 +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 1txErm-00CS6s-9p for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Mar 2025 00:43:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1txErm-00CS6k-06 for pgsql-hackers@lists.postgresql.org; Wed, 26 Mar 2025 00:43:34 +0000 Received: from mail-pl1-x632.google.com ([2607:f8b0:4864:20::632]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1txErk-0018rk-0K for pgsql-hackers@postgresql.org; Wed, 26 Mar 2025 00:43:32 +0000 Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-22409077c06so137919475ad.1 for ; Tue, 25 Mar 2025 17:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1742949811; x=1743554611; darn=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=O1PyIKiybWBJvDllSmXdfC/0IaBbApoHuVRWQUGKee8=; b=HoO4720ErEnUG/TXltb8OFb2VKjelxxX7lIvihqCVxx2mKm6p/h5GUDaxbprt4Da+Y xsHlp59jB2Uyg70cuPHAJ7mIWwAl7SxIkB+E0CH47D3oU8y6n5U+qYJd0wuiNl1TzsMW uanWEptKSoSHkB9RjLju3j8MMhjO8Mxq0YGyA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742949811; x=1743554611; 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=O1PyIKiybWBJvDllSmXdfC/0IaBbApoHuVRWQUGKee8=; b=hnhssQZPHzX0bjAqUCIUugIrDD73pinnVu0FFlYFzG582g+3ZsEGMJTl9oNvU9GFn+ kXDoCCv4fB702l0cNDMP5rfzzdNNYYHC9Q9bx0lkooTUYqfzMyIAC/WkoLYpM6F87WhE 5SvA050ciPzoJR2gEMaqtZeI3fizUbcK2sxOgmCtKOeE/ftcdiCkJojOrN1+KEUiWW8/ 6eB72qUTihyqxfBmsfM0PBv2OyFarum/fx/oawSdTAXL18b2aoL7t2bFuQMrinQQsnlY 9Bipmb9Kc8D18khX+utdhMyuYQW8ShlQdbodhiHE6ImYfMYrH9WSDXyXTamM3w8ElGcV 6XJQ== X-Forwarded-Encrypted: i=1; AJvYcCVzY+FT0KzEGVZlXd7sHFqdZrZgKVccP+UaAY7nT4Ng1Tia6C/dutp1IChKkC7kzb8jZ0JWSCHZbSFRQhuZ@postgresql.org X-Gm-Message-State: AOJu0YxpEg9/dYNdI3+uZDrcZ1DO8zr3+390Bp1jYpEqmHWfCFds1s0M Fa2qdNyznqrKzggsxFly4wzFoTHExddGPhOuu6hVKUjRpyHQLcjJN/Qy07aCCQ== X-Gm-Gg: ASbGnctV9BK8NxEVvPI2DXqVj97Ulf3ft25QW7MRPRLhkbtpdcvqzlaKBFtqSg7LYKQ h2dBkUWgSTz6MhqP1qfrs3E247MAgRbHp3MYtTQ2BSYOyvkFq7XqOvYzwMxWA/ISbcxy7CXTjOL YBQ0elnRyMJ0xNcKz2jhqsw9nlN0ZresI5ptq2/pZ7MVpBrz0wIkyBLX1H1OUF8SMRv2Y20Vi/O GHyn/I4XtBoxuS2/6iDhu2/wk38QvED8fRrZPo+uHQhT1hE9uxoRL2dGBIcYDv966mYmTtbTec7 +fU6MTB14prAQ7da7G8wQ03EgASbU2EFPtgbY4BR+Q== X-Google-Smtp-Source: AGHT+IFB2sjnbEG+6JLvpRytx/2pxAf4ZMQRo4AufSu+0+lge0fQUKODyo58c02HxqhMW4YCbztMvg== X-Received: by 2002:a17:903:2346:b0:224:1c1:4ac1 with SMTP id d9443c01a7336-22780e22b60mr228659095ad.47.1742949810908; Tue, 25 Mar 2025 17:43:30 -0700 (PDT) Received: from google.com ([2601:647:5600:80d0::31cd]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-227e4eca8fbsm20157735ad.26.2025.03.25.17.43.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Mar 2025 17:43:30 -0700 (PDT) Date: Tue, 25 Mar 2025 17:43:28 -0700 From: Noah Misch To: Andres Freund Cc: Antonin Houska , pgsql-hackers@postgresql.org, Thomas Munro , Heikki Linnakangas , Robert Haas , Jakub Wartak , Jelte Fennema-Nio Subject: Re: AIO v2.5 Message-ID: <20250326004328.f6.nmisch@google.com> References: <3yxd5r23zly5bytvgyktbxtxq2r3gbpi7xd4dugevh3h4w4q6c@lu6oatjjpltz> <6ak556uyqiptdwjaci4kbi5eykwkmzqgkbtkyaosjnopjhncrc@2v4ac2jwyz22> <20250325022037.91.nmisch@google.com> <20250325141120.8e.nmisch@google.com> <20250325161543.e3.nmisch@google.com> <7iq4qf7pimeldfrtwv7hazzi4thf2rmaioq6gglzgly4ww6izh@kauuoa3tpyst> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7iq4qf7pimeldfrtwv7hazzi4thf2rmaioq6gglzgly4ww6izh@kauuoa3tpyst> 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 Tue, Mar 25, 2025 at 08:17:17PM -0400, Andres Freund wrote: > On 2025-03-25 09:15:43 -0700, Noah Misch wrote: > > On Tue, Mar 25, 2025 at 11:57:58AM -0400, Andres Freund wrote: > > > FWIW, I prototyped this, it's not hard. > > > > > > But it can't replace the current WARNING with 100% fidelity: If we read 60 > > > blocks in a single smgrreadv, we today would would emit 60 WARNINGs. But we > > > can't encode that many block offset in single PgAioResult, there's not enough > > > space, and enlarging it far enough doesn't seem to make sense either. > > > > > > > > > What we *could* do is to emit one WARNING for each bufmgr.c smgrstartreadv(), > > > with that warning saying that there were N zeroed blocks in a read from block > > > N to block Y and a HINT saying that there are more details in the server log. > > It should probably be DETAIL, not HINT... Either is fine with me. I would go for HINT if referring to the server log, given the precedent of errhint("See server log for query details."). DETAIL fits for block counts, though: > Could use some input on the framing of the message/detail. Right now it's: > > ERROR: invalid page in block 8 of relation base/5/16417 > DETAIL: Read of 8 blocks, starting at block 7, 1 other pages in the same read are invalid. > > But that doesn't seem great. Maybe: > > DETAIL: Read of blocks 7..14, 1 other pages in the same read were also invalid. > > But that still isn't really a sentence. How about this for the multi-page case: WARNING: zeroing out %u invalid pages among blocks %u..%u of relation %s DETAIL: Block %u held first invalid page. HINT: See server log for the other %u invalid blocks. For the one-page case, the old message can stay: WARNING: invalid page in block %u of relation %s; zeroing out page