> After 4 weeks of work, involving alot of bug fixes, and
> documentation improvements, to the source tree, we have just
> released our 4th Beta of 8.0.0. Most of the items on Bruce's
> Open Items list have been completed, but we still have a half
> dozen or so Windows related items still open.
A couple of notes on the three windows items that are open (can't speak
for the non-windows ones that are actually more :P):
* Query cancel in psql
I see two ways of doing this. One is to take the easy way out and just
add a console ctrl handler and let it do a standard query cancel. The
problem with this is that PQrequestCancel() is not thread-safe. Which
means we have a possible crash there, but only if we're either
PQfinish():ing the connection in the main thread, or if we're accessing
the error members (either reading or setting). If this is acceptable,
the fix for psql is really simple.
If this is not acceptable, we have to do something along the line of
what's done in the backend to handle signals - we need to implement a
"signals aware" PQexec(). This function would have to call the async
query functions, and then wait for both these and an internal event to
look for cancel events. This is clearly the safest bet, but it's
definitly more work.
Anybody have any other ideas that happen to be as simple as the first
optino but safer? Please ;-)
* fixed shared memory on Win2k terminal server
I don't see this as a release-blocker. It's certainly nice if we can
find a fix, but if not I think it's perfectly reasonable to say that the
database has to be installed from the console. A lot of other win32
packages require this, including a lot of packages from that big company
over in Redmond.
So my vote is for moving this one off to the normal TODO list.
* Handle "lost signals"
Not really sure how to do this in a good way. We could change the
signals code to queue the signals until a certain function is called
(pgwin32_activate_signals() or whatever). Which would then only be
called after the initial signal handlers are set up.
This will still not save us in the situation that the signal is
delivered *before* the call to pgwin32_signal_initialize(). There is no
way to catch such a signal. We can get close by moving the initialize
function to right at the entry to main() (that will require changing the
error reporting though, it uses ereport as it is now).
Another option for the second point is to have the signal *sender* loop
and send the signal a couple of times in case the receiver has not
opened up the pipe yet. There is no way to see the difference between a
backend-not-yet-ready and a non-postgresql-process though, so it has to
be a limited time. But a backend should get to the
pgwin32_signal_initialize() function pretty fast.
Thoughts?
//Magnus
