Re: Win32 open items - Mailing list pgsql-hackers-win32
From | Magnus Hagander |
---|---|
Subject | Re: Win32 open items |
Date | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE456A32@algol.sollentuna.se Whole thread Raw |
Responses |
Re: Win32 open items
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Win32 open items (Bruce Momjian <pgman@candle.pha.pa.us>) |
List | pgsql-hackers-win32 |
> 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
pgsql-hackers-win32 by date: