Re: Streaming I/O, vectored I/O (WIP)
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
Andres Freund <andres@anarazel.de>,
Melanie Plageman <melanieplageman@gmail.com>
Date: 2023-11-29T23:16:30Z
Lists: pgsql-hackers
On 29/11/2023 21:39, Thomas Munro wrote: > One thing I wasn't 100% happy with was the treatment of ENOSPC. A few > callers believe that short writes set errno: they error out with a > message including %m. We have historically set errno = ENOSPC inside > FileWrite() if the write size was unexpectedly small AND the kernel > didn't set errno to a non-zero value (having set it to zero ourselves > earlier). In FileWriteV(), I didn't want to do that because it is > expensive to compute the total write size from the vector array and we > managed to measure an effect due to that in some workloads. > > Note that the smgr patch actually handles short writes by continuing, > instead of raising an error. Short writes do already occur in the > wild on various systems for various rare technical reasons other than > ENOSPC I have heard (imagine transient failure to acquire some > temporary memory that the kernel chooses not to wait for, stuff like > that, though certainly many people and programs believe they should > not happen[1]), and it seems like a good idea to actually handle them > as our write sizes increase and the probability of short writes might > presumably increase. Maybe we should bite the bullet and always retry short writes in FileWriteV(). Is that what you meant by "handling them"? If the total size is expensive to calculate, how about passing it as an extra argument? Presumably it is cheap for the callers to calculate at the same time that they build the iovec array? > With the previous version of the patch, we'd have to change a couple > of other callers not to believe that short writes are errors and set > errno (callers are inconsistent on this point). I don't really love > that we have "fake" system errors but I also want to stay focused > here, so in this new version V3 I tried a new approach: I realised I > can just always set errno without needing the total size, so that > (undocumented) aspect of the interface doesn't change. The point > being that it doesn't matter if you clobber errno with a bogus value > when the write was non-short. Thoughts? Feels pretty ugly, but I don't see anything outright wrong with that. -- Heikki Linnakangas Neon (https://neon.tech)
Commits
-
Fix typos and incorrect type in read_stream.c
- 2ea4b2927722 17.0 landed
-
Use streaming I/O in pg_prewarm.
- 3a352df05e65 17.0 landed
-
Provide API for streaming relation data.
- b5a9b18cd0bc 17.0 landed
-
Provide vectored variant of ReadBuffer().
- 210622c60e1a 17.0 landed
-
Provide vectored variants of smgrread() and smgrwrite().
- 4908c5872059 17.0 landed
-
Provide multi-block smgrprefetch().
- b485ad7f07c8 17.0 landed
-
Provide vectored variants of FileRead() and FileWrite().
- 871fe4917e1e 17.0 landed
-
Provide helper for retrying partial vectored I/O.
- 0c6be59f5e34 17.0 landed
-
Optimize pg_readv/pg_pwritev single vector case.
- 15c9ac362993 17.0 landed
-
bufmgr: Support multiple in-progress IOs by using resowner
- 12f3867f5534 16.0 cited