Re: Updated logging config (was: Initial eventlog support on win32 )
От | Tom Lane |
---|---|
Тема | Re: Updated logging config (was: Initial eventlog support on win32 ) |
Дата | |
Msg-id | 28351.1090618727@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Updated logging config (was: Initial eventlog support on win32 ) ("Magnus Hagander" <mha@sollentuna.net>) |
Список | pgsql-patches |
"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
В списке pgsql-patches по дате отправления: