Initial eventlog support on win32

Magnus Hagander wrote:

This patch adds initial eventlog support on win32. It's good enough for
most purposes, but we will probably want a specific message DLL later to
format the messages nicer.

I'm extremely happy to see this being done - it's a must-have for WIN32,
I think.

The patch mimcs the syslog handling in most cases. It also hijacks the
syslog guc variable. Since syslog is not available on win32, it's
meaning is redefined as eventlog. So syslog=1 means eventlog+stdout,
syslog=2 means just eventlog.

I'm less happy about this. In fact the 0 | 1 | 2 for syslog is very
hokey anyway. What is more, it is not inconceivable that someone would
run syslogd on a Windows host, especially if it pointed to a remote
syslog. Such things exist, as a quick Google search will demonstrate.
(I'm not sure if we have any API available on WIndows to support it, but
that's another question.)

I would rather see the setting cleaned up and allow zero or more of
stdout, syslog, and eventlog (and it should probably be called
log_destination or some such instead of syslog).

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

Magnus Hagander wrote:

The patch mimcs the syslog handling in most cases. It also hijacks the
syslog guc variable.

I'm less happy about this. In fact the 0 | 1 | 2 for syslog is very
hokey anyway. What is more, it is not inconceivable that someone would
run syslogd on a Windows host, especially if it pointed to a remote
syslog. Such things exist, as a quick Google search will demonstrate.
(I'm not sure if we have any API available on WIndows to support it, but
that's another question.)

I would rather see the setting cleaned up and allow zero or more of
stdout, syslog, and eventlog (and it should probably be called
log_destination or some such instead of syslog).

Agreed. I recall dumping on someone just recently because they proposed
a new GUC variable with a similarly unreadable-except-to-bit-pushers
definition. We should take the opportunity to install a more
user-friendly definition.

As with the other stuff we've been talking about, I see no serious
backwards-compatibility concern for this particular variable, since it's
only likely to get touched in the postgresql.conf file.

regards, tom lane

Magnus Hagander wrote:

The patch mimcs the syslog handling in most cases. It also hijacks
the syslog guc variable.

I'm less happy about this. In fact the 0 | 1 | 2 for syslog is very
hokey anyway. What is more, it is not inconceivable that

someone would

run syslogd on a Windows host, especially if it pointed to a remote
syslog. Such things exist, as a quick Google search will

demonstrate.

(I'm not sure if we have any API available on WIndows to

support it, but

that's another question.)

I would rather see the setting cleaned up and allow zero or more of
stdout, syslog, and eventlog (and it should probably be called
log_destination or some such instead of syslog).

Agreed. I recall dumping on someone just recently because
they proposed a new GUC variable with a similarly
unreadable-except-to-bit-pushers definition. We should take
the opportunity to install a more user-friendly definition.

As with the other stuff we've been talking about, I see no
serious backwards-compatibility concern for this particular
variable, since it's only likely to get touched in the
postgresql.conf file.

Ok. I will updated this patch to include the replacing of the "syslog"
variable with another one that is more flexible.

Based on what Andrew wrote, configuration along the line of:
log_destination stdout
(for default)

log_destination stdout,syslog
(for syslog=2)

log_destination eventlog
(for win32 eventlog only)

etc etc.

Is that what you were thinking of?

//Magnus

Magnus Hagander wrote:

Ok. I will updated this patch to include the replacing of the "syslog"
variable with another one that is more flexible.

Based on what Andrew wrote, configuration along the line of:
log_destination stdout
(for default)

log_destination stdout,syslog
(for syslog=2)

log_destination eventlog
(for win32 eventlog only)

etc etc.

Is that what you were thinking of?

Something like that is what I was thinking of. It would have to be a
string variable (so surrounding quotes would be needed), and you would
need a little routine to parse it, ignoring whitespace etc., and also
make appropriate doc changes. I guess eventlog would be an error on
anything but Windows, and (at least for now) syslog would be an error on
Windows.

Are there any special eventlog settings needed?

cheers

andrew

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

Based on what Andrew wrote, configuration along the line of:
log_destination stdout
(for default)

log_destination stdout,syslog
(for syslog=2)

log_destination eventlog
(for win32 eventlog only)

etc etc.

Should be "stderr" not "stdout". Otherwise looks good. I think you can
find existing infrastructure for parsing a comma-separated list of
keywords in a GUC variable --- look at how DateStyle is handled.

regards, tom lane