Re: logical decoding : exceeded maxAllocatedDescs for .spill files
От | Amit Khandekar |
---|---|
Тема | Re: logical decoding : exceeded maxAllocatedDescs for .spill files |
Дата | |
Msg-id | CAJ3gD9emnEys=R+T3OVt_87DuMpMfS4KvoRV6e=iSi5PT+9f3w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: logical decoding : exceeded maxAllocatedDescs for .spill files (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: logical decoding : exceeded maxAllocatedDescs for .spill files
|
Список | pgsql-hackers |
On Wed, 20 Nov 2019 at 01:05, Thomas Munro <thomas.munro@gmail.com> wrote: > > On Wed, Nov 20, 2019 at 7:58 AM Thomas Munro <thomas.munro@gmail.com> wrote: > > On Wed, Nov 20, 2019 at 1:14 AM Juan José Santamaría Flecha > > > https://devblogs.microsoft.com/oldnewthing/20150121-00/?p=44863 > > > > !?! Thanks Juan and Thomas for pointing to these links where already this was discussed. > > One thing I don't understand (besides, apparently, the documentation): > how did this problem escape detection by check-world for such a long > time? Surely we expect to hit the end of various temporary files in > various tests. Is it intermittent, or dependent on Windows version, > or something like that? Possibly there aren't any callers who try to pread() at end-of-file using FileRead/pg_pread : - mdread() seems to read from an offset which it seems to know that it is inside the end-of file, including the whole BLCKSZ. - BufFileLoadBuffer() seems to deliberately ignore FileRead()'s return value if it is -1 if (file->nbytes < 0) file->nbytes = 0; - XLogPageRead() also seems to know that the offset is a valid offset. -- Thanks, -Amit Khandekar EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: