BUG #6459: logging_collector=off but log_filename set inhibits logoutpu

Started by Christoph Anton Mittererabout 14 years ago5 messagesbugs
Jump to latest
#1Christoph Anton Mitterer
calestyo@scientia.net

The following bug has been logged on the website:

Bug reference: 6459
Logged by: Christoph Anton Mitterer
Email address: calestyo@scientia.net
PostgreSQL version: 9.1.1
Operating system: All
Description:

Hi.

http://www.postgresql.org/docs/9.1/static/runtime-config-logging.html
claims that log_filename is only used when logging_collector is enabled.

However it seems that if the later is off, but the former is set (to
anything), no log output goes to stderr as well.

Cheers,
Chris.

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Christoph Anton Mitterer (#1)
Re: BUG #6459: logging_collector=off but log_filename set inhibits logoutpu

calestyo@scientia.net writes:

http://www.postgresql.org/docs/9.1/static/runtime-config-logging.html
claims that log_filename is only used when logging_collector is enabled.

That is a true statement, as can easily be proven by looking at the
source code: nothing except syslogger.c pays any attention to the
Log_filename variable.

However it seems that if the later is off, but the former is set (to
anything), no log output goes to stderr as well.

That would depend on other settings that you haven't mentioned,
particularly log_destination. Keep in mind also that the active setting
of logging_collector can't be changed without a postmaster restart
(which is why it's a separate variable from log_destination).

regards, tom lane

#3Christoph Anton Mitterer
calestyo@scientia.net
In reply to: Tom Lane (#2)
Re: BUG #6459: logging_collector=off but log_filename set inhibits logoutpu

Hi.

On Tue, 2012-02-14 at 18:45 -0500, Tom Lane wrote:

calestyo@scientia.net writes:

http://www.postgresql.org/docs/9.1/static/runtime-config-logging.html
claims that log_filename is only used when logging_collector is enabled.

That is a true statement, as can easily be proven by looking at the
source code: nothing except syslogger.c pays any attention to the
Log_filename variable.

Well nevertheless,... if set, I get no stderr output at all (which
Debian uses per default as log source).

However it seems that if the later is off, but the former is set (to
anything), no log output goes to stderr as well.

That would depend on other settings that you haven't mentioned,
particularly log_destination. Keep in mind also that the active setting
of logging_collector can't be changed without a postmaster restart
(which is why it's a separate variable from log_destination).

log_destination is commented, thus default stderr should apply.
And of course I've restarted.

Cheers,
Chris.

btw: I'll be on vacation till 1st of March, so don't expect any soon
answers.

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Christoph Anton Mitterer (#3)
Re: BUG #6459: logging_collector=off but log_filename set inhibits logoutpu

Christoph Anton Mitterer <calestyo@scientia.net> writes:

On Tue, 2012-02-14 at 18:45 -0500, Tom Lane wrote:

calestyo@scientia.net writes:

http://www.postgresql.org/docs/9.1/static/runtime-config-logging.html
claims that log_filename is only used when logging_collector is enabled.

That is a true statement, as can easily be proven by looking at the
source code: nothing except syslogger.c pays any attention to the
Log_filename variable.

Well nevertheless,... if set, I get no stderr output at all (which
Debian uses per default as log source).

I wonder whether Debian's startup script is doing something that affects
this? Because it's pretty hard to explain otherwise.

regards, tom lane

#5Christoph Anton Mitterer
calestyo@scientia.net
In reply to: Tom Lane (#4)
Re: BUG #6459: logging_collector=off but log_filename set inhibits logoutpu

On Mon, 2012-02-20 at 00:26 -0500, Tom Lane wrote:

I wonder whether Debian's startup script is doing something that affects
this? Because it's pretty hard to explain otherwise.

You're probably right and I've reported this there:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660649

:)

Cheers,
Chris.