Re: pread() and pwrite()
От | Thomas Munro |
---|---|
Тема | Re: pread() and pwrite() |
Дата | |
Msg-id | CAEepm=0u8ek1i7voxH+tcW2UzC-3QWY+_FRRvGqKN-JR4BQdsQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pread() and pwrite() (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, Jul 21, 2018 at 3:34 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heikki Linnakangas <hlinnaka@iki.fi> writes: > > No objections, if you want to make the effort. But IMHO the lseek+read > > fallback is good enough on Windows. Unless you were thinking that we > > could then remove the !HAVE_PREAD fallback altogether. Are there any > > other platforms out there that don't have pread/pwrite that we care about? > > AFAICT, macOS has them as far back as we care about (prairiedog does). > HPUX 10.20 (gaur/pademelon) does not, so personally I'd like to keep > the lseek+read workaround. Don't know about the oldest Solaris critters > we have in the buildfarm. FreeBSD has had 'em at least since 4.0 (1994); > didn't check the other BSDen. > > SUS v2 (POSIX 1997) does specify both functions, so we could insist on > their presence without breaking any of our own portability guidelines. > However, if we have to have some workaround anyway for Windows, it > seems like including an lseek+read code path is reasonable so that we > needn't retire those oldest buildfarm critters. Yeah it seems useful and cheap to carry the lseek() fallback. But actually there is a good reason to implement proper pread/pwrite (equivalent) on Windows: this patch removes the position tracking, so that the fallback code generates *more* lseek() calls than current master. For example with sequential reads today we are smart enough to skip redundant lseek() calls, but this patch removes those smarts. I doubt anyone cares about that on HPUX 10.20 but I don't think we should do that on Windows. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: