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

On 23-Mar-04, at 4:57 PM, Magnus Hagander wrote:

Something about like this?

Looks good. One trivial gripe: you need to update psql/tab-complete.c

BTW, integrating PostgreSQL with WMI (Windows Management
Instrumentation) would be neat, I think:

http://msdn.microsoft.com/library/en-us/wmisdk/wmi/wmi_start_page.asp

-Neil

On 23-Mar-04, at 4:57 PM, Magnus Hagander wrote:

Something about like this?

Looks good. One trivial gripe: you need to update psql/tab-complete.c

Thanks. Since I've heard nothing else, here is an updated patch that
does this, and also adds some documentation (please double check that
part though - not too sure on the markup).

BTW, integrating PostgreSQL with WMI (Windows Management
Instrumentation) would be neat, I think:

Eventually, it certainly would :-) And the performance monitor. But
that's for the future :-)

//Magnus

Patch applied. Thanks.

---------------------------------------------------------------------------

Magnus Hagander wrote:

On 23-Mar-04, at 4:57 PM, Magnus Hagander wrote:

Something about like this?

Looks good. One trivial gripe: you need to update psql/tab-complete.c

Thanks. Since I've heard nothing else, here is an updated patch that
does this, and also adds some documentation (please double check that
part though - not too sure on the markup).

BTW, integrating PostgreSQL with WMI (Windows Management
Instrumentation) would be neat, I think:

Eventually, it certainly would :-) And the performance monitor. But
that's for the future :-)

//Magnus

Content-Description: logging.patch

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

"Magnus Hagander" <mha@sollentuna.net> writes:

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 ...

regards, tom lane

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

"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

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.

Right.

I was just wondering if the log_destination change had introduced any
new constraints I didn't know about (in particular, what about
eventlog?)

Shouldn't.
The eventlog is automatically initialised the first time it's called in
each process (using the static variable evtHandle). So it shouldn't make
any difference when you change it.

//Magnus