Обсуждение: syslog configurable line splitting behavior
Writing log messages to syslog caters to ancient syslog implementations in two ways: - sequence numbers - line splitting While these are arguably reasonable defaults, I would like a way to turn them off, because they get in the way of doing more interesting things with syslog (e.g., logging somewhere that is not just a text file). So I propose the two attached patches that introduce new configuration Boolean parameters syslog_sequence_numbers and syslog_split_lines that can toggle these behaviors.
Вложения
On Sat, Feb 27, 2016 at 6:49 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
Writing log messages to syslog caters to ancient syslog implementations
in two ways:
- sequence numbers
- line splitting
While these are arguably reasonable defaults, I would like a way to turn
them off, because they get in the way of doing more interesting things
with syslog (e.g., logging somewhere that is not just a text file).
So I propose the two attached patches that introduce new configuration
Boolean parameters syslog_sequence_numbers and syslog_split_lines that
can toggle these behaviors.
Would it have any usage if we make PG_SYSLOG_LIMIT configurable (-1 for disable) instead of introducing boolean?
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 02/27/2016 04:49 AM, Peter Eisentraut wrote: > So I propose the two attached patches that introduce new configuration > Boolean parameters syslog_sequence_numbers and syslog_split_lines that > can toggle these behaviors. As someone who uses syslog for my servers I find both of these GUCs useful, especially when used in combination, and I do not think a compile time option like suggest by Alexander would be suitable substitute because then I would need a custom build of PostgreSQL just to change this which seems too much effort just for this. The code itself is clean and I find the documentation to be easy to understand. I have one nitpick: why is one of the variables "true" while the other is "on" in the example? I think both should be "on". #syslog_sequence_numbers = true #syslog_split_lines = on Another possible improvement would be to change "Split messages sent to syslog." to something more verbose like "Split messages sent to syslog, by lines and to fit in 1024 bytes.". I tested the code and it worked as advertised and also passed the test suite. My local rsyslogd cut the message at about 8 kB, but I do not think it is worth it to expose PG_SYSLOG_LIMIT as a GUC. Andreas
On 3/4/16 11:01 AM, Alexander Korotkov wrote: > On Sat, Feb 27, 2016 at 6:49 AM, Peter Eisentraut <peter_e@gmx.net > <mailto:peter_e@gmx.net>> wrote: > > Writing log messages to syslog caters to ancient syslog implementations > in two ways: > > - sequence numbers > - line splitting > > While these are arguably reasonable defaults, I would like a way to turn > them off, because they get in the way of doing more interesting things > with syslog (e.g., logging somewhere that is not just a text file). > > So I propose the two attached patches that introduce new configuration > Boolean parameters syslog_sequence_numbers and syslog_split_lines that > can toggle these behaviors. > > > Would it have any usage if we make PG_SYSLOG_LIMIT configurable (-1 for > disable) instead of introducing boolean? That would work, too. But then we'd need another setting to disable splitting on newlines. That way we'd have more settings, but they actually mirror the corresponding settings on the rsyslogd side better.
On 3/8/16 9:12 PM, Andreas Karlsson wrote: > As someone who uses syslog for my servers I find both of these GUCs > useful, especially when used in combination, and I do not think a > compile time option like suggest by Alexander would be suitable > substitute because then I would need a custom build of PostgreSQL just > to change this which seems too much effort just for this. I think he was suggesting to take the existing compile-time constant and make a run-time setting out of it.
On 03/09/2016 03:20 AM, Peter Eisentraut wrote: > On 3/8/16 9:12 PM, Andreas Karlsson wrote: >> As someone who uses syslog for my servers I find both of these GUCs >> useful, especially when used in combination, and I do not think a >> compile time option like suggest by Alexander would be suitable >> substitute because then I would need a custom build of PostgreSQL just >> to change this which seems too much effort just for this. > > I think he was suggesting to take the existing compile-time constant and > make a run-time setting out of it. Ah, that makes more sense than my reading of his message. Still I do not think there would be much gain from doing so. I do not see much benefit from making it configurable. In the cases I envision you would either want to split with a log file in mind or not split at all. Andreas
On 3/8/16 9:12 PM, Andreas Karlsson wrote: > I have one nitpick: why is one of the variables "true" while the other > is "on" in the example? I think both should be "on". > > #syslog_sequence_numbers = true > #syslog_split_lines = on > > Another possible improvement would be to change "Split messages sent to > syslog." to something more verbose like "Split messages sent to syslog, > by lines and to fit in 1024 bytes.". Updated patches with your suggestions. I also renamed syslog_split_lines to syslog_split_messages, which I think is more accurate.
Вложения
On 03/16/2016 03:50 AM, Peter Eisentraut wrote: > On 3/8/16 9:12 PM, Andreas Karlsson wrote: >> I have one nitpick: why is one of the variables "true" while the other >> is "on" in the example? I think both should be "on". >> >> #syslog_sequence_numbers = true >> #syslog_split_lines = on >> >> Another possible improvement would be to change "Split messages sent to >> syslog." to something more verbose like "Split messages sent to syslog, >> by lines and to fit in 1024 bytes.". > > Updated patches with your suggestions. I also renamed > syslog_split_lines to syslog_split_messages, which I think is more accurate. I think the patch looks good now. I will change the status to "Ready for committer". Andreas