Re: BUG #13484: Performance problem with logical decoding

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.