On Thu, Jul 12, 2018 at 1:55 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > I guess the only remaining reason to use FileSeek() is to get the file > size? So I wonder why SEEK_SET remains valid in the patch... if my > suspicion is correct that only SEEK_END still has a reason to exist, > perhaps we should just kill FileSeek() and add FileSize() or something > instead?
Done. > pgstat_report_wait_start(wait_event_info); > +#ifdef HAVE_PREAD > + returnCode = pread(vfdP->fd, buffer, amount, offset); > +#else > + lseek(VfdCache[file].fd, offset, SEEK_SET); > returnCode = read(vfdP->fd, buffer, amount); > +#endif > pgstat_report_wait_end(); > > This obviously lacks error handling for lseek(). Fixed. Updated the main WAL IO routines to use pread()/pwrite() too. Not super heavily tested yet. An idea for how to handle Windows, in a follow-up patch: add a file src/backend/port/win32/file.c that defines pgwin32_pread() and pgwin32_pwrite(), wrapping WriteFile()/ReadFile() and passing in an "OVERLAPPED" struct with the offset and sets errno on error, then set up the macros so that Windows can use them as pread(), pwrite(). It might also be necessary to open all files with FILE_FLAG_OVERLAPPED. Does any Windows hacker have a bettter idea, and/or want to try to write that patch? Otherwise I'll eventually try to do some long distance hacking on AppVeyor. -- Thomas Munro http://www.enterprisedb.com
0001-Use-pread-pwrite-instead-of-lseek-read-write-v2.patch
Description: Binary data
