Re: logical decoding : exceeded maxAllocatedDescs for .spill files
От | Thomas Munro |
---|---|
Тема | Re: logical decoding : exceeded maxAllocatedDescs for .spill files |
Дата | |
Msg-id | CA+hUKG+uibiwfe9NJh0YU-VckV7qeHwmmxqc7jXOLrJGhiS-5g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: logical decoding : exceeded maxAllocatedDescs for .spill files (Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>) |
Список | pgsql-hackers |
On Wed, Nov 20, 2019 at 1:14 AM Juan José Santamaría Flecha <juanjo.santamaria@gmail.com> wrote: > On Tue, Nov 19, 2019 at 12:49 PM Thomas Munro <thomas.munro@gmail.com> wrote: >> On Wed, Nov 20, 2019 at 12:28 AM Amit Khandekar <amitdkhan.pg@gmail.com> wrote: >> > 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. >> >> Hmm. See also this report: >> >> https://www.postgresql.org/message-id/flat/CABuU89MfEvJE%3DWif%2BHk7SCqjSOF4rhgwJWW6aR3hjojpGqFbjQ%40mail.gmail.com > > The files from pgwin32_open() are open for synchronous access, while pg_pread() uses the asynchronous functionality tooffset the read. Under these circunstances, a read past EOF will return ERROR_HANDLE_EOF (38), as explained in: > > https://devblogs.microsoft.com/oldnewthing/20150121-00/?p=44863 FWIW, I sent a pull request to see if the MicrosoftDocs project agrees that the ReadFile page is misleading on this point: https://github.com/MicrosoftDocs/sdk-api/pull/7
В списке pgsql-hackers по дате отправления: