Logfile created when not needed?
Digging into several win32 related issues right now, so I don't have the
time to investigate ATM, but I figured I should get it out here:
If I configure log_destination='eventlog', and then
redirect_stderr='on', PostgreSQL will attempt to create a logfile in
pg_log anyway. This file remains empty (at least through my test), but
it is created, and if it fails to be created, the postmaster won't start
at all.
I may be missing something and there is a point to this, but if it's
never used it should probably not be created in the first place, should
it?
(I would assume the same thing happens if you set
log_destination='syslog', but haven't tested that)
//Magnus
"Magnus Hagander" <mha@sollentuna.net> writes:
If I configure log_destination='eventlog', and then
redirect_stderr='on', PostgreSQL will attempt to create a logfile in
pg_log anyway.
So don't do that --- redirect_stderr is only sensible to turn on if you
mean to use logging to stderr.
The reason we don't attempt to enforce this is that log_destination is
legal to change after startup, whereas we can't change redirect_stderr
on-the-fly (because existing backends wouldn't have their stderr tied to
the right place).
I'm not sure how sensible it really is to switch dynamically between
logging to stderr and logging someplace else, but as long as the code
can support that, why not allow it ...
regards, tom lane
If I configure log_destination='eventlog', and then
redirect_stderr='on', PostgreSQL will attempt to create alogfile in
pg_log anyway.
So don't do that --- redirect_stderr is only sensible to turn
on if you mean to use logging to stderr.
I don't. Normally. But I had it turned on, then changed log_destination
and forgot..
The reason we don't attempt to enforce this is that
log_destination is legal to change after startup, whereas we
can't change redirect_stderr on-the-fly (because existing
backends wouldn't have their stderr tied to the right place).
Ok. Fair 'nuf.
//Magnus