On Tue, Mar 25, 2025 at 11:57:58AM -0400, Andres Freund wrote: > On 2025-03-25 07:11:20 -0700, Noah Misch wrote: > > On Mon, Mar 24, 2025 at 10:52:19PM -0400, Andres Freund wrote: > > > If we want to implement it, I think we could introduce PGAIO_RS_WARN, > > > which > > > then could tell the stager to issue the WARNING. It would add a bit of > > > distributed cost, both to callbacks and users of AIO, but it might not be > > > too > > > bad. > > 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.
Sounds fine. > > Another thought on complete_shared running on other backends: I wonder if we > > should push an ErrorContextCallback that adds "CONTEXT: completing I/O of > > other process" or similar, so people wonder less about how "SELECT FROM a" > > led > > to a log message about IO on table "b". > > I've been wondering about that as well, and yes, we probably should. > > I'd add the pid of the backend that started the IO to the message - although > need to check whether we're trying to keep PIDs of other processes from > unprivileged users. We don't. > I think we probably should add a similar, but not equivalent, context in io > workers. Maybe "I/O worker executing I/O on behalf of process %d". Sounds good.
