Skip site navigation (1) Skip section navigation (2)

Re: PATCH: Limit 100 default in frmEditGrid.cpp

From: Matteo Bertini <matteo(at)naufraghi(dot)net>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: PATCH: Limit 100 default in frmEditGrid.cpp
Date: 2009-01-12 10:50:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
On 12-01-2009 10:49, Dave Page wrote:
> On Sat, Jan 10, 2009 at 1:58 AM, Matteo Bertini<matteo(at)naufraghi(dot)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)]

Choose a big table,
click on view,
close the windows before the data is ready

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/
#2  0xf693ac3e in ssl3_read_n () from /usr/lib/i686/cmov/
#3  0xf693b045 in ssl3_read_bytes () from /usr/lib/i686/cmov/
#4  0xf69389a6 in ssl3_read () from /usr/lib/i686/cmov/
#5  0xf694a96f in SSL_read () from /usr/lib/i686/cmov/
#6  0xf72a0e3d in pqsecure_read () from /usr/lib/
#7  0xf7299427 in pqReadData () from /usr/lib/
#8  0xf72971ac in PQconsumeInput () from /usr/lib/
#9  0x080dc421 in pgQueryThread::execute (this=0x8fc1500) at 
#10 0x080dc92d in pgQueryThread::Entry (this=0x8fc1500) at 
#11 0xf7523896 in wxThreadInternal::PthreadStart (thread=0x8fc1500)
     at ../src/unix/threadpsx.cpp:766
#12 0xf752399d in wxPthreadStart (ptr=0x8fc1500) at 
#13 0xf7157f3b in start_thread () from /lib/
#14 0xf70deb6e in clone () from /lib/

In response to


pgadmin-hackers by date

Next:From: Quan ZongliangDate: 2009-01-12 11:13:09
Subject: Re: SVN Commit by dpage: r7544 - in trunk/pgadmin3: . pgadmin/frm pgadmin/include/utils pgadmin/ui
Previous:From: Dave PageDate: 2009-01-12 09:49:21
Subject: Re: PATCH: Limit 100 default in frmEditGrid.cpp

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group