Обсуждение: 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