Обсуждение: Re: Updated logging config (was: Initial eventlog support on win32 )

Поиск
Список
Период
Сортировка

Re: Updated logging config (was: Initial eventlog support on win32 )

От
"Magnus Hagander"
Дата:
>> Remove 'syslog' GUC variable, and add more logical 'log_destination'
>> variable to control logoutput location on Unix and Win32.
>
>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.
(same goes for syslog-ident).

I see no direct reason why you shouldn't be able to change it via at
SIGHUP.


//Magnus

Re: Updated logging config (was: Initial eventlog support on win32 )

От
Tom Lane
Дата:
"Magnus Hagander" <mha@sollentuna.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