On Wed, Nov 20, 2019 at 12:28 AM Amit Khandekar <amitdkhan.pg@gmail.com> wrote: > On Tue, 19 Nov 2019 at 14:07, Amit Kapila <amit.kapila16@gmail.com> wrote: > > No, I got this before applying the patch. However, after applying the > > patch, I got below error in the same test: > > > > postgres=# SELECT 1 from > > pg_logical_slot_get_changes('regression_slot', NULL,NULL) LIMIT 1; > > ERROR: could not read from reorderbuffer spill file: Invalid argument > > > > It seems to me that FileRead API used in the patch can return value < > > 0 on EOF. See the API usage in BufFileLoadBuffer. I got this error > > on a windows machine and in the server log the message was "LOG: > > unrecognized win32 error code: 38" which indicates "Reached the end of > > the file." > > On Windows, it is documented that ReadFile() (which is called by > pg_pread) will return false on EOF but only when the file is open for > asynchronous reads/writes. But here we are just dealing with usual > synchronous reads. So pg_pread() code should indeed return 0 on EOF on > Windows. Not yet able to figure out how FileRead() managed to return > this error on Windows. But from your symptoms, it does look like > pg_pread()=>ReadFile() returned false (despite doing asynchronous > reads), and so _dosmaperr() gets called, and then it does not find the > eof error in doserrors[], so the "unrecognized win32 error code" > message is printed. May have to dig up more on this.
The files from pgwin32_open() are open for synchronous access, while pg_pread() uses the asynchronous functionality to offset the read. Under these circunstances, a read past EOF will return ERROR_HANDLE_EOF (38), as explained in:
