Re: BUG #13484: Performance problem with logical decoding

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: BUG #13484: Performance problem with logical decoding
Дата
Msg-id 20150706212332.GG340@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: BUG #13484: Performance problem with logical decoding  (Andres Freund <andres@anarazel.de>)
Ответы Re: BUG #13484: Performance problem with logical decoding  (olivier.gosseaume@free.fr)
Список pgsql-bugs
On 2015-07-06 23:21:26 +0200, Andres Freund wrote:
> On 2015-07-06 23:05:27 +0200, Andres Freund wrote:
> > Ugh, I have a theory. I guess you can't easily recompile postgres with a
> > patch and test again? I don't have access to windows...
>
> 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.

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: BUG #13484: Performance problem with logical decoding
Следующее
От: olivier.gosseaume@free.fr
Дата:
Сообщение: Re: BUG #13484: Performance problem with logical decoding