Обсуждение: Initial eventlog support on win32

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.

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.

For reviews and application to head if nobody objects.

//Magnus

 <<eventlog.patch>>

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