Skip site navigation (1) Skip section navigation (2)

Re: win32 signals, part 4

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Claudio Natoli" <claudio(dot)natoli(at)memetrics(dot)com>
Cc: "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: win32 signals, part 4
Date: 2004-02-05 09:08:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
> > >If there are no further comments from Claudio or anyone 
> else, I feel 
> > >this is now ready to be applied.
> Code walkthrough looks good.
> One final minor point to discuss: 
> 	Is being unable to set a handler for things like 
> CTRL_C_EVENT, CTRL_SHUTDOWN_EVENT etc really a non-fatal 
> error? ISTM that, if we can't guarantee to cleanly handle 
> externally generated signals (like a shutdown
> request) or those that could occur internally (like, say, 
> SIGFPE, which I'm guessing you'll get to), then we probably 
> ought to bail.

Yes, I think it's non-fatal :-)
In any production environment, you are going to be running postgresql as
a service. In that case it's not up to the console ctrl handler to
handle these events, but the service manager. Since it's not a console
program, I assume (no, haven't tested) that it will/may fail in this
And if you're just testing, you will want it to run with a warning..

Any integration with the Service Control Manager will come later.
Depending on how that it done, this might change. I suggest we revisit
it then.

Also, if we fail the console ctrl handler, the default handler will
always be used. This one will terminate the process, similar to "kill
-9" on Unix. While not the nice thing to do, the database shuold still
survive this. The events will not be totally ignored.

(And yes, I'll be getting to SIGFPE).


pgsql-hackers-win32 by date

Next:From: Zeugswetter Andreas SB SDDate: 2004-02-05 11:45:32
Subject: Re: [HACKERS] Sync vs. fsync during checkpoint
Previous:From: Claudio NatoliDate: 2004-02-05 06:34:50
Subject: Re: Win32 regression tests

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group