Dave Page wrote:
>>
>>"Dave Page" <dpage@vale-housing.co.uk> writes:
>>
>>>The attached patch directs FATAL and PANIC elog's to the
>>
>>event log as
>>
>>>well as their normal destination.
>>
>>I don't think this is a good idea. In the first place, FATAL
>>errors are not necessarily serious or out-of-the-ordinary ---
>>an example is that all authorization errors are FATAL.
>
>
> OK, I could live with just panics.
Logging auth failures will be interesting for admins too. This could
indicate an ongoing attack. I would keep FATAL.
>>In
>>the second place, the proposed patch deliberately subverts
>>what the DBA has set as the logging output parameters. I
>>dislike software that knows better than I do what I want and
>>is willing to ignore what I told it to do on those grounds.
>
>
> Logging like this is fairly normal on Windows. Applications may maintain
> their own (often verbose) logfiles, however more serious errors get
> directed to the event log as well. This allows automated monitoring of
> servers to be achieved for example.
It must be stressed that win32 eventlog behaves very different from
linux syslog. And what the DBA wants to know, is not necessarily what
the sys admin (domain admin) wants to know. Frankly, i doubt that plain
eventlog logging will be used widely in the presence of redirect_stderr
(and tools to read them); the behaviour is too non-windowish.
>
> One possible solution would be to use our own event log which is
> possible in 2K+, (but not NT).
This is very uncommon, even for MS software. AFAICS only system software
(intrinsic to win32) does so. I wonder how many eventlog monitoring
programs already know about that possibility...
>>A patch that would be more in the spirit of Postgres is to
>>allow different min_log_level values for the different
>>possible log destinations (stderr, syslog, eventlog).
>>However that looks a lot like a new feature to me, so maybe
>>it will have to wait for 8.1.
>
>
> Yes, that would work, though as you say it's a new feature.
No doubt, the best solution.
Regards,
Andreas
