Re: pg_preadv() and pg_pwritev()
От | Tom Lane |
---|---|
Тема | Re: pg_preadv() and pg_pwritev() |
Дата | |
Msg-id | 341497.1608420857@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pg_preadv() and pg_pwritev() (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: pg_preadv() and pg_pwritev()
|
Список | pgsql-hackers |
Thomas Munro <thomas.munro@gmail.com> writes: > I want to be able to do synchronous vectored file I/O, so I made > wrapper macros for preadv() and pwritev() with fallbacks for systems > that don't have them. Following the precedent of the pg_pread() and > pg_pwrite() macros, the "pg_" prefix reflects a subtle contract > change: the fallback paths might have the side effect of changing the > file position. In a quick look, seems OK with some nits: 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. 2. I'm not really that happy about loading <sys/uio.h> into every compilation we do, which would be another reason for a new specialized header that either includes <sys/uio.h> or provides fallback definitions. 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? regards, tom lane
В списке pgsql-hackers по дате отправления: