>> 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