Andrew Dunstan wrote:
>>> I have just discovered that the recently implemented pipe chunking
>>> protocol is broken on Windows. This is because the pipes are operating
>>> in text mode and doing LF->CR-LF translation, so the number of bytes
>>> received is not the number transmitted and set in the protocol header.
>>>
>>> I have not yet succeeded in turning this behaviour off (_setmode()
>>> didn't seem to affect it). If we can't find a way to turn it off, the
>>> only solution short of abandoning its use on Windows that I can think of
>>> is to translate LF on input to something unlikely like 0x1C and then
>>> translate it back when we read it from the pipe.
>>>
>>
>> At what point does it actually do the translation? Meaning what
>> system/library call has it?
>>
>> Are we using the pipes from src/port/pipe.c? It does sound a bit weird
>> that they'd do that, since it's basically just emulating stuff over
>> standard tcp sockets, but perhaps something is broken in that code?
>>
>> Sorry, haven't really checked up on the chunk code yet, so I don't know
>> offhand where to look.
>>
>>
>>
>
> It looks like we aren't. In fact. it looks like the only call to
> pgpipe() in the whole source tree is in the syslogger and it's in
> specifically non-Windows code, meaning that that whole file is currently
> useless.
Uh, see port.h, lines 212-224. If you're using the pipe() command to
create it, it's used.
> Maybe you should have a good look at src/backend/postmaster/syslogger.c.
> If we could get rid of the pipe-read threads and all the special Windows
> cruft there that would certainly be an advance.
I'll try to squeeze some time in to do that - I'll have to read up on
the whole pipe/chunk thing first though, so it'll be a while.
//Magnus