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

[redirecting]

Dave Page wrote:

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

I am more and more coming to the conclusion that we should either remove
NT4 as a supported platform, or at least surround it with very
significant caveats. M$ is about to end the last remaining bit of
support for it, and has already stopped publishing non-security fixes.

It looks like there are lots of legacy installations still out there
(heck, I see lots of RH7.3 and it's also out of support).

But there isn't any legacy native W32 Postgres, so we would not be
affecting any legacy users by not supporting NT4.

Thoughts?

cheers

andrew

Andrew Dunstan wrote:

[redirecting]

Dave Page wrote:

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

I am more and more coming to the conclusion that we should either remove
NT4 as a supported platform, or at least surround it with very
significant caveats. M$ is about to end the last remaining bit of
support for it, and has already stopped publishing non-security fixes.

It looks like there are lots of legacy installations still out there
(heck, I see lots of RH7.3 and it's also out of support).

But there isn't any legacy native W32 Postgres, so we would not be
affecting any legacy users by not supporting NT4.

What is the downside of supporting NT4 if we can?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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

Andrew Dunstan wrote:

I am more and more coming to the conclusion that we should either remove
NT4 as a supported platform, or at least surround it with very
significant caveats. M$ is about to end the last remaining bit of
support for it, and has already stopped publishing non-security fixes.

Thoughts?

Primarily, I agree. But I became a bit uncertain when I recently saw the
support request from an Indian user who wanted to run on win98, which is
certainly even harder than NT.

I wonder how many people would not have the chance to try pgsql because
they can't afford a system that's sufficiently up to date.

We have limited resources, so we'll have to concentrate on main stream;
older platforms shouldn't restrict the functionality of the standard
installer.
OTOH, if somebody has the time to create support documents so
non-supported win32 platforms can be used too, this would be probably
appreciated.

My .02 social cents.

Regards,
Andreas

Bruce Momjian wrote:

Andrew Dunstan wrote:

I am more and more coming to the conclusion that we should either remove
NT4 as a supported platform, or at least surround it with very
significant caveats. M$ is about to end the last remaining bit of
support for it, and has already stopped publishing non-security fixes.

It looks like there are lots of legacy installations still out there
(heck, I see lots of RH7.3 and it's also out of support).

But there isn't any legacy native W32 Postgres, so we would not be
affecting any legacy users by not supporting NT4.

What is the downside of supporting NT4 if we can?

It's that "if" I am concerned about. I think Dave and Merlin have just
showed us that, in addition to the eventlog limitations, there are
enough other reasons to say we really can't.

As for Andreas' point about people wanting to try PostgreSQL out on
low-cost platforms, if they need Windows they can use Cygwin still, and
otherwise they can use Linux or FreeBSD.

The point is that we have limited resources, and should not strain them
trying to support a platform that is itself unsupported and that makes
life difficult/impossible for us. If we had legacy users it might be a
different story.

cheers

andrew

Andrew Dunstan wrote:

Bruce Momjian wrote:

Andrew Dunstan wrote:

I am more and more coming to the conclusion that we should either remove
NT4 as a supported platform, or at least surround it with very
significant caveats. M$ is about to end the last remaining bit of
support for it, and has already stopped publishing non-security fixes.

It looks like there are lots of legacy installations still out there
(heck, I see lots of RH7.3 and it's also out of support).

But there isn't any legacy native W32 Postgres, so we would not be
affecting any legacy users by not supporting NT4.

What is the downside of supporting NT4 if we can?

It's that "if" I am concerned about. I think Dave and Merlin have just
showed us that, in addition to the eventlog limitations, there are
enough other reasons to say we really can't.

As for Andreas' point about people wanting to try PostgreSQL out on
low-cost platforms, if they need Windows they can use Cygwin still, and
otherwise they can use Linux or FreeBSD.

The point is that we have limited resources, and should not strain them
trying to support a platform that is itself unsupported and that makes
life difficult/impossible for us. If we had legacy users it might be a
different story.

I guess I am waiting for someone to report it doesn't work on NT4 SP4.
How do we know it doesn't work?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073