Re: PATCH: Limit 100 default in frmEditGrid.cpp - Mailing list pgadmin-hackers
From | Matteo Bertini |
---|---|
Subject | Re: PATCH: Limit 100 default in frmEditGrid.cpp |
Date | |
Msg-id | 496B2079.6050703@naufraghi.net Whole thread Raw |
In response to | Re: PATCH: Limit 100 default in frmEditGrid.cpp ("Dave Page" <dpage@pgadmin.org>) |
Responses |
Re: PATCH: Limit 100 default in frmEditGrid.cpp
Re: PATCH: Limit 100 default in frmEditGrid.cpp |
List | pgadmin-hackers |
On 12-01-2009 10:49, Dave Page wrote: > On Sat, Jan 10, 2009 at 1:58 AM, Matteo Bertini<matteo@naufraghi.net> wrote: > >> I propose a small patch to frmEditGrid.cpp that changes the default limit >> form "No limit" to "100 rows". >> > I'm not sure that's something we want to change - I don't recall it > ever being requested before, and personally I think I'd find it > annoying. > What is your use case for no limit? I use the view just for: 1) check/modify a few records (<< 1000) 2) have a look at the data in one click Both of this use cases are not influenced by a default limit (let's say 500, even 1000, but << infinity) > What I would be happier with is a drop-down menu on the View Data > button which gave access to the different options as the context menu > does. The button itself would then run the last option selected from > the drop-down menu (exactly as the plugins button does). > Yes, the "promoted" option and the last-selected config are a good for me. >> Another option, more coherent in design to the rest of the program, can be >> disabling automatic run and let the user configure the option before. I >> think there are a small number of forms that are performing long operation >> at the show time without the explicit user action. >> > Eh? There s an explicit user action - you clicked 'View Data' > Yes and no, that is the only button can cause a long action without further user action, all the other buttons are 1) immediate 2) are showing a form for further config. >> Besides usability, the problem I found is a segfault happening when the >> table is huge (mine is 14e6 records) and the frmEditGrid is closed before >> the load is complete. In my configuration the crash is reproducible with >> version 1.8.4 and trunk. >> > Can you get a backtrace from the crash? > Something like this? (I reconfigured pgadmin3 with --enable-debug) (gdb) run Starting program: /home2/bertini/src/pgadmin3/pgadmin/pgadmin3 [Thread debugging using libthread_db enabled] [New process 14512] [New Thread -163538160 (LWP 14512)] [New Thread -168051824 (LWP 14693)] [Thread -168051824 (zombie) exited] [New Thread -176501872 (LWP 14694)] <actions> Choose a big table, click on view, close the windows before the data is ready </actions> Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -176501872 (LWP 14694)] 0x091792c0 in ?? () (gdb) bt #0 0x091792c0 in ?? () #1 0xf687014c in BIO_read () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 #2 0xf693ac3e in ssl3_read_n () from /usr/lib/i686/cmov/libssl.so.0.9.8 #3 0xf693b045 in ssl3_read_bytes () from /usr/lib/i686/cmov/libssl.so.0.9.8 #4 0xf69389a6 in ssl3_read () from /usr/lib/i686/cmov/libssl.so.0.9.8 #5 0xf694a96f in SSL_read () from /usr/lib/i686/cmov/libssl.so.0.9.8 #6 0xf72a0e3d in pqsecure_read () from /usr/lib/libpq.so.4 #7 0xf7299427 in pqReadData () from /usr/lib/libpq.so.4 #8 0xf72971ac in PQconsumeInput () from /usr/lib/libpq.so.4 #9 0x080dc421 in pgQueryThread::execute (this=0x8fc1500) at ./db/pgQueryThread.cpp:113 #10 0x080dc92d in pgQueryThread::Entry (this=0x8fc1500) at ./db/pgQueryThread.cpp:197 #11 0xf7523896 in wxThreadInternal::PthreadStart (thread=0x8fc1500) at ../src/unix/threadpsx.cpp:766 #12 0xf752399d in wxPthreadStart (ptr=0x8fc1500) at ../src/unix/threadpsx.cpp:718 #13 0xf7157f3b in start_thread () from /lib/libpthread.so.0 #14 0xf70deb6e in clone () from /lib/libc.so.6 (gdb)
pgadmin-hackers by date: