On Tue, Oct 29, 2019 at 9:23 PM ZhenHua Cai <zhhua.cai@gmail.com> wrote:
> No, it doesn't call any in-core code.
I wondered if this could be coming from the new code in
src/port/pg_p{read,write}.c. ERROR_HANDLE_EOF is a documented
GetLastError() return value after ReadFile() fails[1], but only for
asynchronous files. We are using that interface ("overlapped" IO,
their name for asynchronous IO, but the same interface can also do
synchronous IO and happens to support an offset like Unix's pread()),
but we're not opening file handles with FILE_FLAG_OVERLAPPED so we
have a plain old synchronous handle here.
Searching the web for ERROR_HANDLE_EOF leads to a least one
discussion[2] of "mailslots" (like our syslog pipe?) and a couple of
possible underlying NT errors, and following those leads some other
stuff about SMB filesystems and sockets. Is your database running on
a local or SMB (or other remote) filesystem? Are you using the
PostgreSQL syslog process? I don't know anything about Windows at all
but from these breadcrumbs I feel like there has to be a network or
asynchronous communication involved somewhere here, not a plain old
end-of-file on a regular synchronous file operation, which, as Tom
said, we have code paths for that don't look like this (because that
just shows up as 0 bytes read).
[1] https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile
[2] https://stackoverflow.com/questions/56510727/what-causes-writefile-to-return-error-38-error-handle-eof
