Re: BUG #13484: Performance problem with logical decoding
От | olivier.gosseaume@free.fr |
---|---|
Тема | Re: BUG #13484: Performance problem with logical decoding |
Дата | |
Msg-id | 1803533379.17196016.1436219313665.JavaMail.root@zimbra72-e12.priv.proxad.net обсуждение исходный текст |
Ответ на | Re: BUG #13484: Performance problem with logical decoding (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #13484: Performance problem with logical decoding
|
Список | pgsql-bugs |
>> So the problem I'm seing is that there's a typo/bug in >> ReorderBufferSerializeTXN(). It closes the filehandle after each >> individual spilled file instead of keeping it open for up to 16MB of >> WAL. On linux that doesn't hurt particularly much, the file isn't >> flushed to disk. Which presumably is why we haven't noticed. But if >> windows does that differently... >Hrmpf, just sent the last part of this message to a different thread. >The fix is just to change > if (fd == -1 || XLByteInSeg(change->lsn, curOpenSegNo)) >into > if (fd == -1 || !XLByteInSeg(change->lsn, curOpenSegNo)) > >the bug doesn't have any correctness implications afaics, just >performance. We read all the spilled files till the end, so even change >spilled to the wrong segment gets picked up. Great. I will try to rebuild on Windows with this patch and let you know Olivier
В списке pgsql-bugs по дате отправления: