Re: Don't synchronously wait for already-in-progress IO in read stream - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Don't synchronously wait for already-in-progress IO in read stream
Date
Msg-id us6m5jdjxmveyan77tdg2tysjls4yu3tsohpvjjedz6pnjkyn7@2g6b2asvgug3
Whole thread
In response to Re: Don't synchronously wait for already-in-progress IO in read stream  (Andres Freund <andres@anarazel.de>)
Responses Re: Don't synchronously wait for already-in-progress IO in read stream
Re: Don't synchronously wait for already-in-progress IO in read stream
List pgsql-hackers
Hi,

I think I forgot to update the thread in my last message to note that I
had committed some of the preliminary changes.


On 2026-03-26 20:12:30 -0400, Andres Freund wrote:
> One test used did_io=(t|f). That was actually only needed once "aio: Don't
> wait for already in-progress IO" is in, as we might join the foreign IO. I
> chose to hide that by making that part of the query "did_io and not
> foreign_io", so we would detect if we were to falsely start IO ourselves.

I ended up not liking did_io, as that seems misleading when we just needed to
wait for a foreign IO.  I instead named it io_reqd.


> Still need to extend the test as part of the "don't wait" commit, to actually
> ensure that we reach the path for joining foreign IO.

That's done now.  I've added verification that we don't wrongly recognize
in-progress-ios without a wref as a foreign IO and an injection point based
test that verifies that we do see the foreign IO.

I've also done a bunch of cleanup in the commits. A few typos in commit
messages and the actual code changes and a few larger changes in the test code
& infrastructure. Mostly as part of allowing the aforementioned testing
(read_buffers() now only waits at the end, to make some of the tests
possible), but also just making the modified code a bit cleaner.

Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Roberto Mello
Date:
Subject: Re: pg_publication_tables: return NULL attnames when no column list is specified
Next
From: Tom Lane
Date:
Subject: Re: Update documentation for SET to include SCHEMA / NAMES syntax