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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings