Date: Tue, 1 Apr 2025 08:11:59 -0700
From: Noah Misch <noah@leadboat.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>,
	Heikki Linnakangas <hlinnaka@iki.fi>,
	Robert Haas <robertmhaas@gmail.com>,
	Jakub Wartak <jakub.wartak@enterprisedb.com>,
	Jelte Fennema-Nio <postgres@jeltef.nl>,
	Antonin Houska <ah@cybertec.at>
Subject: Re: AIO v2.5
Message-ID: <20250401151159.51.nmisch@google.com>
References: <5tyic6epvdlmd6eddgelv47syg2b5cpwffjam54axp25xyq2ga@ptwkinxqo3az>
 <20250328032223.34.nmisch@google.com>
 <wkjj4p2rmkevutkwc6tewoovdqznj6c6nvjmvii4oo5wmbh5sr@retq7d6uqs4j>
 <ym3dqpa4xcvoeknewcw63x77vnqdosbqcetjinb2zfoh65k55m@m4ozmwhr6lk6>
 <20250329134143.ca.nmisch@google.com>
 <d4ff3qxudxn2ze3zk2xwhds5ysezfei3uqeuimymj624t5chsd@sgr2h3rmln5t>
 <wouqlwmsxbgak4kow7p4s6g4voh2bai7b4acy324v4ncgh2nnq@5r5o6nvghsko>
 <20250329212929.a6.nmisch@google.com>
 <usbwzckj7q3jhfx3ann3nrfnukmupbs35axvq5zfyeo6nvrzrm@onjhxs2du4st>
 <7s6fclfekpcxoaaorwrq67v4vmgixf2dcjcgznuj7vxs3ie3wq@okqbi5vabqbx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7s6fclfekpcxoaaorwrq67v4vmgixf2dcjcgznuj7vxs3ie3wq@okqbi5vabqbx>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: 
 <https://www.postgresql.org/message-id/20250401151159.51.nmisch%40google.com>
Precedence: bulk

On Mon, Mar 31, 2025 at 08:41:39PM -0400, Andres Freund wrote:
> updated version

All non-write patches (1-7) are ready for commit, though I have some cosmetic
recommendations below.  I've marked the commitfest entry Ready for Committer.

> +		# Check a page validity error in another block, to ensure we report
> +		# the correct block number
> +		$psql_a->query_safe(
> +			qq(
> +SELECT modify_rel_block('tbl_zero', 3, corrupt_header=>true);
> +));
> +		psql_like(
> +			$io_method,
> +			$psql_a,
> +			"$persistency: test zeroing of invalid block 3",
> +			qq(SELECT read_rel_block_ll('tbl_zero', 3, zero_on_error=>true);),
> +			qr/^$/,
> +			qr/^psql:<stdin>:\d+: WARNING:  invalid page in block 3 of relation base\/.*\/.*; zeroing out page$/
> +		);
> +
> +
> +		# Check a page validity error in another block, to ensure we report
> +		# the correct block number

This comment is a copy of the previous test's comment.  While the comment is
not false, consider changing it to:

		# Check one read reporting multiple invalid blocks.

> +		$psql_a->query_safe(
> +			qq(
> +SELECT modify_rel_block('tbl_zero', 2, corrupt_header=>true);
> +SELECT modify_rel_block('tbl_zero', 3, corrupt_header=>true);
> +));
> +		# First test error
> +		psql_like(
> +			$io_method,
> +			$psql_a,
> +			"$persistency: test reading of invalid block 2,3 in larger read",
> +			qq(SELECT read_rel_block_ll('tbl_zero', 1, nblocks=>4, zero_on_error=>false)),
> +			qr/^$/,
> +			qr/^psql:<stdin>:\d+: ERROR:  2 invalid pages among blocks 1..4 of relation base\/.*\/.*\nDETAIL:  Block 2 held first invalid page\.\nHINT:[^\n]+$/
> +		);
> +
> +		# Then test zeroing via ZERO_ON_ERROR flag
> +		psql_like(
> +			$io_method,
> +			$psql_a,
> +			"$persistency: test zeroing of invalid block 2,3 in larger read, ZERO_ON_ERROR",
> +			qq(SELECT read_rel_block_ll('tbl_zero', 1, nblocks=>4, zero_on_error=>true)),
> +			qr/^$/,
> +			qr/^psql:<stdin>:\d+: WARNING:  zeroing out 2 invalid pages among blocks 1..4 of relation base\/.*\/.*\nDETAIL:  Block 2 held first zeroed page\.\nHINT:[^\n]+$/
> +		);
> +
> +		# Then test zeroing vio zero_damaged_pages

s/vio/via/

> +# Verify checksum handling when creating database from an invalid database.
> +# This also serves as a minimal check that cross-database IO is handled
> +# reasonably.

To me, "invalid database" is a term of art from the message "cannot connect to
invalid database".  Hence, I would change "invalid database" to "database w/
invalid block" or similar, here and below.  (Alternatively, just delete "from
an invalid database".  It's clear from the context.)

> +	if (corrupt_checksum)
> +	{
> +		bool		successfully_corrupted = 0;
> +
> +		/*
> +		 * Any single modification of the checksum could just end up being
> +		 * valid again. To be sure
> +		 */

Unfinished sentence.  That said, I'm not following why we'd need this loop.
If this test code were changing the input to the checksum, it's true that an
input bit flip might reach the same pd_checksum.  The test case is changing
pd_checksum, not the input bits.  I don't see how changing pd_checksum could
leave the page still valid.  There's only one valid pd_checksum value for a
given input page.

> +			/*
> +			 * The underlying IO actually completed OK, and thus the "invalid"
> +			 * portion of the IOV actually contains valid data. That can hide
> +			 * a lot of problems, e.g. if we were to wrongly mark a buffer,
> +			 * that wasn't read according to the shortened-read, IO as valid,
> +			 * the contents would look valid and we might miss a bug.

Minimally s/read, IO/read IO,/ but I'd edit a bit further:

			 * a lot of problems, e.g. if we were to wrongly mark-valid a
			 * buffer that wasn't read according to the shortened-read IO, the
			 * contents would look valid and we might miss a bug.

> Subject: [PATCH v2.15 05/18] md: Add comment & assert to buffer-zeroing path
>  in md[start]readv()

> The zero_damaged_pages path is incomplete, as as missing segments are not

s/as as/as/

> For now, put an Assert(false) comments documenting this choice into mdreadv()

s/comments/and comments/

> +				 * For PG 18, we are putting an Assert(false) in into
> +				 * mdreadv() (triggering failures in assertion-enabled builds,

s/in into/in/

> Subject: [PATCH v2.15 06/18] aio: comment polishing

> + * - Partial reads need to be handle by the caller re-issuing IO for the
> + *   unread blocks

s/handle/handled/

> Subject: [PATCH v2.15 07/18] aio: Add errcontext for processing I/Os for
>  another backend