Thread: Crash on Database Reconnect
Hi, * Platform - Windows XP Professional (32-bit) * Language - English * Distribution - binary * Version - 1.14.3 (June 2012, rev; REL-1_14_3) (Note: Help >> About should allow the user to copy the version number...) Reproduce Crash 1. Connect to a VPN 2. Connect to a database over the VPN 3. Drill down and select a table 4. Open a SQL window 5. Type in a select statement (e.g., select * from an_existing_table_name) 6. Press F5 to execute the select statement 7. Disconnect the VPN 8. Reconnect the VPN 9. Press F5 to execute the select statement 10. Confirm reconnect. You should see: ********** Error ********** Connection reset. 11. Press F5 again. (This might -- or might not -- run the query successfully. This is the crash point.) 12. Disconnect the VPN 13. Reconnect the VPN 14. Repeat until steps 9 to 14 until crash. I can reproduce a crash in fewer than four VPN connect/disconnect cycles. Expected Results No matter how often the database connection is severed (I have a *very* flaky VPN connection), pgAdmin should reconnect to the database and continue functioning without locking up or crashing. Actual Results Eventually, pgAdmin locks up or crashes. Related Feature Request Add a crash handler so that when pgAdmin crashes, it can recover any code in any SQL window the user had open at the time of crashing. In other words, never, ever, ever, ever lose user's work. Fortunately, I hit CTRL+s quite often so I didn't lose much. However, there should be an option to auto-save (even to a temporary file if no file name is provided) before executing any SQL statement. Upon recovery pgAdmin should ask the user whether or not the recovery files should be reloaded or discarded. Kindest regards,
I've had this happen regularly as well (on Windows 7 x64), though I cannot reproduce it reliably. Also fully agree on auto-recovering the users work, I'd love to see that implemented. On 19/08/2012 8:02 AM, Thangalin wrote: > Hi, > > * Platform - Windows XP Professional (32-bit) > * Language - English > * Distribution - binary > * Version - 1.14.3 (June 2012, rev; REL-1_14_3) (Note: Help >> About > should allow the user to copy the version number...) > > Reproduce Crash > 1. Connect to a VPN > 2. Connect to a database over the VPN > 3. Drill down and select a table > 4. Open a SQL window > 5. Type in a select statement (e.g., select * from an_existing_table_name) > 6. Press F5 to execute the select statement > 7. Disconnect the VPN > 8. Reconnect the VPN > 9. Press F5 to execute the select statement > 10. Confirm reconnect. > > You should see: > > ********** Error ********** > > > Connection reset. > > 11. Press F5 again. (This might -- or might not -- run the query > successfully. This is the crash point.) > 12. Disconnect the VPN > 13. Reconnect the VPN > 14. Repeat until steps 9 to 14 until crash. > > I can reproduce a crash in fewer than four VPN connect/disconnect cycles. > > Expected Results > No matter how often the database connection is severed (I have a > *very* flaky VPN connection), pgAdmin should reconnect to the database > and continue functioning without locking up or crashing. > > Actual Results > Eventually, pgAdmin locks up or crashes. > > Related Feature Request > Add a crash handler so that when pgAdmin crashes, it can recover any > code in any SQL window the user had open at the time of crashing. In > other words, never, ever, ever, ever lose user's work. Fortunately, I > hit CTRL+s quite often so I didn't lose much. However, there should be > an option to auto-save (even to a temporary file if no file name is > provided) before executing any SQL statement. Upon recovery pgAdmin > should ask the user whether or not the recovery files should be > reloaded or discarded. > > Kindest regards, > >
On Sat, 2012-08-18 at 15:02 -0700, Thangalin wrote: > Hi, > > * Platform - Windows XP Professional (32-bit) > * Language - English > * Distribution - binary > * Version - 1.14.3 (June 2012, rev; REL-1_14_3) (Note: Help >> About > should allow the user to copy the version number...) > > Reproduce Crash > 1. Connect to a VPN > 2. Connect to a database over the VPN > 3. Drill down and select a table > 4. Open a SQL window > 5. Type in a select statement (e.g., select * from an_existing_table_name) > 6. Press F5 to execute the select statement > 7. Disconnect the VPN > 8. Reconnect the VPN > 9. Press F5 to execute the select statement > 10. Confirm reconnect. > > You should see: > > ********** Error ********** > > > Connection reset. > > 11. Press F5 again. (This might -- or might not -- run the query > successfully. This is the crash point.) > 12. Disconnect the VPN > 13. Reconnect the VPN > 14. Repeat until steps 9 to 14 until crash. > > I can reproduce a crash in fewer than four VPN connect/disconnect cycles. > > Expected Results > No matter how often the database connection is severed (I have a > *very* flaky VPN connection), pgAdmin should reconnect to the database > and continue functioning without locking up or crashing. > > Actual Results > Eventually, pgAdmin locks up or crashes. > What error message do you have when it crashes? > Related Feature Request > Add a crash handler so that when pgAdmin crashes, it can recover any > code in any SQL window the user had open at the time of crashing. In > other words, never, ever, ever, ever lose user's work. Fortunately, I > hit CTRL+s quite often so I didn't lose much. However, there should be > an option to auto-save (even to a temporary file if no file name is > provided) before executing any SQL statement. Upon recovery pgAdmin > should ask the user whether or not the recovery files should be > reloaded or discarded. > Someone's already working on this. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Thu, 2012-09-13 at 17:40 -0700, Thangalin wrote: > Hi, Guillaume. > > I wish I could give you more details about the bug. > > It happened so many times. Whenever the VPN disconnected, I > reconnected the VPN, reconnected to the database, used pgAdmin III for > a while, then it would crash. > Yeah, it appears we have an issue with network connectivity going up and down. This is something we should work on. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On 15/09/12 18:31, Guillaume Lelarge wrote: > On Thu, 2012-09-13 at 17:40 -0700, Thangalin wrote: >> Hi, Guillaume. >> >> I wish I could give you more details about the bug. >> >> It happened so many times. Whenever the VPN disconnected, I >> reconnected the VPN, reconnected to the database, used pgAdmin III for >> a while, then it would crash. >> > > Yeah, it appears we have an issue with network connectivity going up and > down. This is something we should work on. > > I think that my crashes are related to this too, i manage some databases connected by VPN and sometimes the connection goes down and up with the PgAdmin3 session open. Regards, Miguel Angel.