Hi, On 2020-12-20 16:26:42 +1300, Thomas Munro wrote: > > 1. port.h cannot assume that <limits.h> has already been included; > > nor do I want to fix that by including <limits.h> there. Do we > > really need to define a fallback value of IOV_MAX? If so, > > maybe the answer is to put the replacement struct iovec and > > IOV_MAX in some new header. > > Ok, I moved all this stuff into port/pg_uio.h.
Can we come up with a better name than 'uio'? I find that a not exactly meaningful name. Or perhaps we could just leave the functions in port/port.h, but extract the value of the define at configure time? That way only pread.c / pwrite.c would need it. > > 3. The patch as given won't prove anything except that the code > > compiles. Is it worth fixing at least one code path to make > > use of pg_preadv and pg_pwritev, so we can make sure this code > > is tested before there's layers of other new code on top? > > OK, here's a patch to zero-fill fresh WAL segments with pwritev(). I think that's a good idea. However, I see two small issues: 1) If we write larger amounts at once, we need to handle partial writes. That's a large enough amount of IO that it's much more likely to hit a memory shortage or such in the kernel - we had to do that a while a go for WAL writes (which can also be larger), if memory serves. Perhaps we should have pg_pwritev/readv unconditionally go through pwrite.c/pread.c and add support for "continuing" partial writes/reads in one central place? > I'm drawing a blank on trivial candidate uses for preadv(), without > infrastructure from later patches. Can't immediately think of something either. Greetings, Andres Freund
