Re: problem with pgadmin 1.8.2 to keep connection to postgresql 8.2.6 - Mailing list pgadmin-support
From | Sebastian Reitenbach |
---|---|
Subject | Re: problem with pgadmin 1.8.2 to keep connection to postgresql 8.2.6 |
Date | |
Msg-id | 20080520080156.DA5C9414B5@smtp.l00-bugdead-prods.de Whole thread Raw |
In response to | problem with pgadmin 1.8.2 to keep connection to postgresql 8.2.6 ("Sebastian Reitenbach" <sebastia@l00-bugdead-prods.de>) |
Responses |
Re: problem with pgadmin 1.8.2 to keep connection to postgresql 8.2.6
|
List | pgadmin-support |
Hi, "Dave Page" <dpage@pgadmin.org> wrote: > On Fri, May 16, 2008 at 4:16 PM, Sebastian Reitenbach > <sebastia@l00-bugdead-prods.de> wrote: > > "Dave Page" <dpage@pgadmin.org> wrote: > >> On Fri, May 16, 2008 at 12:05 PM, Sebastian Reitenbach > >> <sebastia@l00-bugdead-prods.de> wrote: > >> > I also tried to run pgadmin3 --sync, as on another time when it crashed, > > it > >> > suggested to use this parameter. But then, the problem was not > > reproducible, > >> > because the query seems to take forever, the counter of miliseconds in > > the > >> > lower right corner was at about 50000 when I stopped it. The query run > > from > >> > pgadmin without --sync parameter took only about 40ms. > >> > >> Well that's, umm surprising. There is no --sync option in pgAdmin - in > >> fact I get an error if I try to use it on Windows or Mac (I don't have > >> a GTK system here atm). Can you get an exact copy of the text which > >> recommended you use it? > > Afaik the error message came from the X server, so yes, not a pgadmin3 > > parameter. > > It said sth. like: > > When an X application crashes, the error message is asynchron, and therefore > > usually not shows the real cause of the problem. When you want to run the > > application from within gdb, then use --sync, to get the right backtrace. > > The --sync is I think automatically added to each X application, from the X > > server, or window manager, whoever there is responsible. > > Hmm, OK - I did wonder if it were something like that. > > > When I get the error again, then I cut 'n past the output in here, I got > > this only once. > > Please do. FWIW, there are no known bugs in pgAdmin that would cause > connections to drop as you describe (in fact, the connections are > handled by libpq, so it would be largely out of our control anyway) - > and it should be handled gracefully by pgAdmin when it does happen for > other reasons. I have heard a report in the past that for one person > that wasn't the case, but I was unable to reproduce any problems when > deliberately causing connection problems. sorry, it took me a while to get back to the machines again, however, here is the error output cut 'n pasted: So, after submitting the same query, for about 10 times, then instead of the result set, the following was shown in the sql output window of pgadmin3: ********** Error ********** Then, when I try to submit the query again, an error popup window shows up, stating the following: ================================== An error has occurred: no connection to the server ================================== and at the same time, on the console the following appears: ================================== Xlib: sequence lost (0xd5bf8 > 0xc5bfa) in reply type 0xf! Xlib: unexpected async reply (sequence 0xc5c81)! ================================== When I then try to close the error window, it is not closing, I klick the "close" or "ok" or however the button is called, the button several times, and then pgadmin3 disappears at all, leaving the following message on the console: ================================== The program 'pgadmin3' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAtom (invalid Atom parameter)'. (Details: serial 967950 error_code 5 request_code 18 minor_code 0) (Noteto programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causingit. To debug your program, run it with the --sync command line option to change this behavior. You can then geta meaningful backtrace from your debugger if you break on the gdk_x_error() function.) ================================== I also retested, with psql from commandline, using the same query, and I was able to issue it about 50 times in a fast row, before I stopped again. I also tried pgadmin 1.8.1, and I did ran into the same problem, but it seems that the problem does not occur so fast, but maybe that was just coincidence. Sebastian
pgadmin-support by date: