On Jul 27, 2007, at 6:45 PM, Jim Nasby wrote:
On Jul 26, 2007, at 2:03 PM, Tom Lane wrote:
So maybe the *real* question to ask is why we have separate GUCs for
stats_row_level and stats_block_level. Shouldn't we fold them into a
single switch? It's hard to see what having just one of them
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
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
Erik Jones [EMAIL PROTECTED] writes:
improvement that went into that release. I could test turning it
back on this week if you like -- I certainly would like to have my
blks_read/cach_hits stats back. Toggling stats_block_level will
respond to a reload, yes?
Yes, as long as you had
Magnus Hagander wrote:
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
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
Magnus Hagander wrote:
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
Andrew Dunstan wrote:
Uh, see port.h, lines 212-224. If you're using the pipe() command to
create it, it's used.
No, it's the other way around :-) If you use pgpipe() on Unix you're
calling pipe():
D'oh. You're right, of course. I'm obviously not in a state where I
should be reading C
korry.douglas wrote:
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
Andrew Dunstan wrote:
I have no idea why that's done - it goes back to the origins of the
syslogger - probably because someone mistakenly thinks all WIndows
text files have to have CRLF line endings.
I tried changing that to _O_BINARY, and calling _setmode on both the
pipe before it's duped
Andreas Pflug wrote:
Andrew Dunstan wrote:
I have no idea why that's done - it goes back to the origins of the
syslogger - probably because someone mistakenly thinks all WIndows
text files have to have CRLF line endings.
I tried changing that to _O_BINARY, and calling _setmode on both the
Andrew Dunstan wrote:
I have no idea why that's done - it goes back to the origins of the
syslogger - probably because someone mistakenly thinks all WIndows
text files have to have CRLF line endings.
Yes this was intentional, notepad still doesn't like LF line endings.
Not my preferred text
Andreas Pflug wrote:
Andrew Dunstan wrote:
I have no idea why that's done - it goes back to the origins of the
syslogger - probably because someone mistakenly thinks all WIndows
text files have to have CRLF line endings.
Yes this was intentional, notepad still doesn't
Andrew Dunstan wrote:
Not for Wordpad though, and it's pretty universal too. And Notepad
won't load a file of any great size anyway. Furthermore, we just can't
have this alongside the pipe chunking protocol, so I'm inclined to
blow it away altogether, unless there are pretty loud squawks.
Andreas Pflug wrote:
Andrew Dunstan wrote:
Not for Wordpad though, and it's pretty universal too. And Notepad
won't load a file of any great size anyway. Furthermore, we just can't
have this alongside the pipe chunking protocol, so I'm inclined to
blow it away altogether, unless there
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
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
Andreas Pflug wrote:
Andrew Dunstan wrote:
I have no idea why that's done - it goes back to the origins of the
syslogger - probably because someone mistakenly thinks all WIndows
text files have to have CRLF line endings.
I tried changing that to _O_BINARY, and calling _setmode on both the
18 matches
Mail list logo
