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
