Re: pread() and pwrite()

On Thu, Jul 12, 2018 at 1:55 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)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