From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Updated logging config (was: Initial eventlog support on win32 ) |
Date: | 2004-07-23 21:38:47 |
Message-ID: | 28351.1090618727@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
>> I just noticed that this patch seems to have replaced a PGC_SIGHUP
>> config item (the syslog flag) with a PGC_POSTMASTER config item
>> (log_destination). What was the reason for the downgrade in
>> flexibility? If it was discussed before, I've forgotten ...
> Not that I can remember.
> If I do remember correctly, what I did was copy the entry for
> syslog-facility. Which is set as PGC_POSTMASTER. I don't know if there
> is rationale behind that one, but I think that's where I got it from.
Yeah, syslog_facility and _ident are PGC_POSTMASTER because once a
backend (or the postmaster) has done openlog() there is no provision
for doing it over to fix the facility/ident settings. (This could be
fixed if anyone was sufficiently motivated, but I've heard no requests
so far.)
However, there certainly wasn't any reason that the syslog-vs-stderr
switch couldn't be flipped on the fly; the only reason it's even
PGC_SIGHUP was we wanted to enforce that all backends are doing the
same thing at any given time.
I was just wondering if the log_destination change had introduced any
new constraints I didn't know about (in particular, what about eventlog?)
This is possibly relevant to Andreas Pflug's patch in progress...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2004-07-23 21:40:38 | Re: logfile subprocess and Fancy File Functions |
Previous Message | Magnus Hagander | 2004-07-23 21:23:41 | Re: Updated logging config (was: Initial eventlog support on win32 ) |