pqsignal - to be or (in this case) not to be

AKA department of second thoughts once you tested.

I guess I've spent too much time listening to people, including myself,
assuming how things work without actually testing it.

It turns out that both select() and recv() (and thus, probably send() as
well) put the thread in alertable state. This means that while we are in
a blocking select() or recv(), *our signals will be delivered using an
APC*.

What does this mean? Well, no need for our own implementation of
select(). No need for any cruft around the recv() parts of libpq
(especially nice when you start considering SSL). Etc.

I have confirmed this by strace:ing a backend. At the time of blocking,
we get this:
NtWaitForSingleObject (1948, 1, {-1, 2147483647}, ...

Which clearly shows the alertable flag set to 1...

This makes a lot of things easier. I can't beleive I missed this one
before, but I guess I was too busy considering how difficult it would be
to work around the (non existant) issue...

See my latest patch for one that works fine, and does not use any cruft.

Note - we stil need to put PG_POLL_SIGNALS() here and there, because ATM
we can only receive signals when performing a network I/O wait. This may
be fine for the postmaster, but we can for example not cancel a query as
it is now...

//Magnus