[ redirecting to a more appropriate list ]
han.holl@informationslogik.nl writes:
> I've noticed that, even though I specified LOCAL5 as syslog facility, postgres
> nevertheless logs _some_ events to LOCAL0.
I've thought of a theory about this: if the first write_syslog() call
occurs before guc.c has read the config file and set Syslog_facility
to LOCAL5, then the facility value would get locked down as the default
LOCAL0 and subsequently never changed.
Since write_syslog() certainly wouldn't be called until Log_destination
is changed from its default, the triggering situation would have to be
an elog call occuring between the assignments to Log_destination and
Syslog_facility --- ie, an elog coming from guc.c itself. But that
doesn't seem out of the question at all.
The problem with this theory as an explanation for Han's report is that
he says only "some" events are reported to LOCAL0. Under this theory
a postmaster that had gotten into this mode would *always* report to
LOCAL0, and so would all its children (at least in non-EXEC_BACKEND
builds, which is to say any non-Windows build). Han, can you quantify
"some" any better?
> Log lines look like:
> Oct 14 08:55:02 pavenlo root palga [local] SELECT: [17-1] LOG: duration: \
> 2953.658 ms statement: select rapnaam from udps where ((geboortedatum = \
> '1954-01-21') and (naamman ~ '^thie'))
> Oct 14 08:55:02 pavenlo root palga [local] SELECT: [17-2] limit 1000
Another strange thing here is that the funny log entries don't show the
PID of the originating process. Since we *always* call openlog() with
the LOG_PID flag bit, this should be impossible.
> +preload_libraries =
> '/usr/prod/postgres/rubriek:rub_initialize,/usr/prod/postgres/drap,/usr/prod/postgres/naam'
Han, what are these libraries? Is it possible that any of them are
issuing openlog() calls?
regards, tom lane