Thread: Win32 Event log

Under Win32 it is normal for serious errors to be recorded to the
systems event log as well as any log that the application may also be
writing (SQL Server is a good example of an app that does this).

The attached patch directs FATAL and PANIC elog's to the event log as
well as their normal destination. If the normal destination is the event
log, then they are not duplicated. This allows serious errors to be
picked up quickly and easily without swamping the event log (which
generally has limited size) with other events.

Please apply for beta 2...

Cheers, Dave.

"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.  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.  In the
third place, no one is going to have any difficulty picking out PANICs
from "other events" ;-)

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.

            regards, tom lane

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 12 August 2004 15:40
> To: Dave Page
> Cc: PostgreSQL Patches
> Subject: Re: [PATCHES] Win32 Event log
>
> "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.

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

> In the third place, no one is going to have any difficulty
> picking out PANICs from "other events" ;-)

Finding them is not so much the problem - it's the fact that the event
log on Windows has a limited size (default 1024Kb on XP) and will
overwrite old events as required. The sort of output you might see from
a busy PostgreSQL server could potentially wipe out relatively new
entries made by other apps.

One possible solution would be to use our own event log which is
possible in 2K+, (but not NT).

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

Regards, Dave.

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