Another XP Pro experience
От | David P. Caldwell |
---|---|
Тема | Another XP Pro experience |
Дата | |
Msg-id | 3E225043.6090801@inonit.com обсуждение исходный текст |
Ответы |
Re: Another XP Pro experience
|
Список | pgsql-cygwin |
Everyone: I figured since others have been reporting issues with XP/Cygwin/PostgreSQL, I'd chime in with my own observations. (XP Pro SP1, Cygwin 1.3.18-1, PostgreSQL 7.2.3-2, cygipc 1.13-2), and make sure they (and any comments others add) get into the archives. (1) I didn't have the problem some have reported with with ipc-daemon --install-as-service; it worked fine for me. (2) I have been having intermittent failures. It took hours to even figure out how to replicate them, but I believe I have the pattern: In XP Pro, more than one user can be logged in interactively (a user can, rather than logging off, "Switch User", which leaves the first user's processes running). I have a privileged user (root) and an unprivileged user (me), in addition to the postgres user. AFAICT, the second user to log on to Windows cannot connect using psql (or seemingly by any other method). So if a user logs into the system, then another user logs in, the second can't connect. This is irrespective of RUNAS, etc. -- if I'm logged in as root on the GUI, I can connect as root, postgres, and/or me from that, uh, session (I don't know the Windows term for this). If I then switch users (without logging out of root), I can't connect as any user from the other GUI session. The message in the log under these circumstances is: postmaster: StreamConnection: accept: Connection aborted I also have an application which connects via JDBC running as a service on this box, and it appears to display similar behavior, though I haven't focused on using that application as a test case (I've been using psql). It's possible that I'll be able to come up with even more specific detail on what triggers the problem, but these are my conclusions after about 20 minutes of "confirmation" testing (logging in and out continuously is tedious work, and I had of course considered and discarded about 20 theories before even considering the possibility that the user ID of the session might matter in any way). Whether this is at the PostgreSQL level or the Cygwin level (or the cygipc level), I have no idea (not much of a Windows/UNIX hacker myself). This isn't a huge showstopper for me now that I know the rules, though it will lead to minor inconvenience now and again. If anyone wants me to run any other tests or check anything else, I'd be glad to do so (I don't want to bore you with cygcheck or anything unless there's some promising avenue down which someone wants to venture). -- David.
В списке pgsql-cygwin по дате отправления: