Re: Win32 signal code - first try

> I think we should start thinking more about how this code
> will be integrated into the source as a whole. Couple of
> outstanding issues:
>
> 1. Are there any security issues related to the pipe
> server...can we guarantee that incoming signals are coming
> from the postmaster?

The security is by default:
Same user that created the pipe: READ/WRITE
Administrators: READ/WRITE
Everyone else: READ

That should be safe, IMHO. I was looking at getting rid of the "Everyone
else" part, I'd like to avoid having to create our own security
descriptors if possible. If we want to be NT4 compatible, we can't use
the "easy" functinos to build them. Nor can we use ATL, since we are in
C and not C++.

> 2. How does a sleeping backend (waiting on command) get
> interrupted so that it handles a signal?
My idea was by using WaitFor..Ex() with alertable=true.

> Also, from over the weekend:
>
> 1. I vote not to use PulseEvent...there is almost always a
> better solution 2. I think readfile should stay on the pipe
> server main thread but the WriteFile should get moved. I see
> no advantage to reading the incoming signals asynchronously
> and it could cause some problems.
Ok. It was just an extra security measure. I still think it's good, and
I don't think it adds a lot more complexity (all this stuff has to be
protected from multithread access anyway).
Looking at your security question above, it could possibly be an issue
if someone in the "everyone else" group connected with read access only,
and never sent anything. Which would be avoided with the separate thread
doing the read as well.

> Also, remember that all signal handling in postgres goes
> through an interface (pgsignal.c) that handles implementation
> specific details. These interface routines are a very
> convenient place to put OS specific calls without dirtying
> the code base.
Yes, that is very good. All we need to put elsewhere then are the poll
calls, and the initialization call (or is there one for that as well?
Don't have the code around here right now)

> I suggest reconsidering an event managed from within the main
> backend thread to do signal blocking, in combination with the
> bitmask you guys suggested to do filtering.
Why is this necessary, specifically? I'm not fully in on that :-) As
long as the bitmask of blocked signals (and queued ones) are protected
with a crit sect?

//Magnus