Re: [PATCHES] Win32 Event log

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: 12 August 2004 15:40
> To: Dave Page
> Cc: PostgreSQL Patches
> Subject: Re: [PATCHES] Win32 Event log
>
> "Dave Page" <dpage(at)vale-housing(dot)co(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)vale-housing(dot)co(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073