Skip site navigation (1) Skip section navigation (2)

syslogger line-end processing infelicity

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: syslogger line-end processing infelicity
Date: 2007-06-01 21:15:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I have been looking at the syslogger code in connection with the CSV log 
output proposal, and I'm quite concerned about the way it translates 
every \n into \r\n for Windows output. This has several problems, not 
least of which is that we can by no means assume that every \n has no 
semantic significance. Consider the following:

INSERT INTO mytable (textfield) VALUES ($$abc

Now if the line ending there is in fact \r\n we will output \r\r\n for 
it, and if it is just \n we will output \r\n, and in neither case will 
we be logging what is actually inserted.

My first thought is that we might need to distinguish between newlines 
embedded in the query, which shouldn't be touched, from the newline at 
the end of the log line.

My second thought is that we should quite possibly abandon this 
translation altogether - we know that our COPY code is quite happy with 
either style of line ending, as long as the file is consistent, and also 
many Windows programs will quite happily read files with Unix style line 
endings (e.g. Wordpad, although not Notepad).

My third thought is that even so my first thought has some virtue :-). 
We really need to ensure that we only rotate files when we are at a 
genuine end of log line - the situation that Greg Smith described of 
having the rotator chop a line in two between two files seem wholly 





pgsql-hackers by date

Next:From: Ed L.Date: 2007-06-01 21:20:19
Subject: Re: query log corrupted-looking entries
Previous:From: George PavlovDate: 2007-06-01 21:09:04
Subject: Re: query log corrupted-looking entries

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group