________________________________

From: pgsql-general-owner@postgresql.org
[mailtogsql-general-owner@postgresql.org] On Behalf Of Kenneth Downs
Sent: 12 May 2006 02:09
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] GUI Interface


The longer you use it, the longer it takes to connect to
databases each time you start up. It says "Restoring previous
settings".


It should only take longer if the number of objects in your database
grows significantly, or if you've turned on debug logging. At that point
it is examining your database so that it can rebuild the treeview to
roughly the state that it was when you last used it.

I am considering making that behaviour optional though - I have many
databases for instance, and often find myself wating a few seconds
needlessly.



On my linux box, it also has the dubious honor of being the
only program I have ever seen that can lock X hard, with killing the X
server being the only rescue (if you call that a rescue). It can
connect over networks, but on mine it always seems to hang after an hour
or so, and you have to kill it and restart it.


That's a new one. Any other symptoms? Can you get a backtrace from a
coredump?


Finally, it ain't great for inspecting text columns.



How so- the in-grid editor? I'm open to suggestions and feedback.

Regards, Dave.

Dave Page wrote:

>
>
> ------------------------------------------------------------------------
> *From:* pgsql-general-owner@postgresql.org
> [mailtogsql-general-owner@postgresql.org] *On Behalf Of *Kenneth
> Downs
> *Sent:* 12 May 2006 02:09
> *To:* pgsql-general@postgresql.org
> *Subject:* Re: [GENERAL] GUI Interface
>
> The longer you use it, the longer it takes to connect to databases
> each time you start up. It says "Restoring previous settings".
>
>
> It should only take longer if the number of objects in your database
> grows significantly, or if you've turned on debug logging. At that
> point it is examining your database so that it can rebuild the
> treeview to roughly the state that it was when you last used it.

My database has 270+ tables. That's probably small for where it will be
in a year. At the moment I have only a dozen or so databases per
server, and four servers that I regularly connect to. I did not
intentionally turn on debug logging.

>
> I am considering making that behaviour optional though - I have many
> databases for instance, and often find myself wating a few seconds
> needlessly.

Yeah, it's hard to complain about seconds, but delays of that sort do
upset concentration. The problem is compounded when I have to kill it
and restart it for a network hang.

>
>
> On my linux box, it also has the dubious honor of being the only
> program I have ever seen that can lock X hard, with killing the X
> server being the only rescue (if you call that a rescue). It can
> connect over networks, but on mine it always seems to hang after
> an hour or so, and you have to kill it and restart it.
>
>
> That's a new one. Any other symptoms? Can you get a backtrace from a
> coredump?

I'll answer this in another email, I'm about to deliberately freeze my X
server and won't be able to answer

>
> Finally, it ain't great for inspecting text columns.
>
>
>
> How so- the in-grid editor? I'm open to suggestions and feedback.

The results display in the query analyzer shows one results at one row
height. If a text column has CR's in it, such as the text of a stored
procedure, or a stored XML file, you can't see anything. There appears
no way to increase the height of the displayed result, so all I see is
the first line. Ideal would be a display that sized itself to the
height of the content. Then I'd be clean out of phppgadmin.

phppgadmin has the edge here because they simply dump the result to the
display and the browser sizes it.

>
> Regards, Dave.




---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Dave Page wrote:

> On my linux box, it also has the dubious honor of being the only
> program I have ever seen that can lock X hard, with killing the X
> server being the only rescue (if you call that a rescue). It can
> connect over networks, but on mine it always seems to hang after
> an hour or so, and you have to kill it and restart it.
>
>
> That's a new one. Any other symptoms? Can you get a backtrace from a
> coredump?
>
The good news is I could not reproduce it. But when it happens again
I'll know who to notify.

As I recall, the problem would occur in the query analyzer. If there
was highlighted text in the top window, and you highlighted a row in the
results, and then clicked into the upper window while dragging the
mouse, it would freeze the X server. It has happened much much less
often lately, but it did happen just two days ago, and it always
involves a click-drag situation.




---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Kenneth Downs schrieb:
> Dave Page wrote:
>
>> On my linux box, it also has the dubious honor of being the only
>> program I have ever seen that can lock X hard, with killing the X
>> server being the only rescue (if you call that a rescue). It can
>> connect over networks, but on mine it always seems to hang after
>> an hour or so, and you have to kill it and restart it.
>>
>>
>> That's a new one. Any other symptoms? Can you get a backtrace from a
>> coredump?
>>
> The good news is I could not reproduce it. But when it happens again
> I'll know who to notify.
>
> As I recall, the problem would occur in the query analyzer. If there
> was highlighted text in the top window, and you highlighted a row in the
> results, and then clicked into the upper window while dragging the
> mouse, it would freeze the X server. It has happened much much less
> often lately, but it did happen just two days ago, and it always
> involves a click-drag situation.

Yes, that seems a gtk issue. You mark, then klick accidentaly into
the marked text (usually to change the mark area) and in the result
you are dragging the text to nowhere. pgadmin and X freezes in this
case. However you can login via another box and just kill pgadmin
to unfreeze. Maybe there is a problem with how drag & drop
is/isnt handled by the code? I have no idea.

Regards
Tino Wildenhain

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Kenneth Downs wrote:
> Dave Page wrote:
>>
>>
>> ------------------------------------------------------------------------
>> *From:* pgsql-general-owner@postgresql.org
>> [mailtogsql-general-owner@postgresql.org] *On Behalf Of
>> *Kenneth Downs
>> *Sent:* 12 May 2006 02:09
>> *To:* pgsql-general@postgresql.org
>> *Subject:* Re: [GENERAL] GUI Interface
>>
>> The longer you use it, the longer it takes to connect to
>> databases each time you start up. It says "Restoring previous
>> settings".
>>
>>
>> It should only take longer if the number of objects in your database
>> grows significantly, or if you've turned on debug logging. At that
>> point it is examining your database so that it can rebuild the
>> treeview to roughly the state that it was when you last used it.
> My database has 270+ tables. That's probably small for where it will
> be in a year. At the moment I have only a dozen or so databases per
> server, and four servers that I regularly connect to. I did not
> intentionally turn on debug logging.

Part of the problem is that pgAdmin III seems to preload object
properties instead of pulling them in as you need them.
I have noticed many times in pgAdmin III that when a function is edited
and saved by someone else on a different workstation I can't see those
changes until I manually
refresh the object. When you have a ton of tables etc that
preloading/caching has to be taking up some time.

PGLA only populates the tree with the object names, and when you double
click or right click to edit, then and only then is the object data
brought back and displayed.

When Lazarus(http://www.lazarus.freepascal.org/) becomes more stable I
will create a port of PGLA that will run on Linux and Mac OS X.

--
Tony Caduto
AM Software Design
http://www.amsoftwaredesign.com
Home of PG Lightning Admin for Postgresql
Your best bet for Postgresql Administration


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Tino Wildenhain wrote:
> Kenneth Downs schrieb:
>> Dave Page wrote:
>>> On my linux box, it also has the dubious honor of being the only
>>> program I have ever seen that can lock X hard, with killing the X
>>> server being the only rescue (if you call that a rescue). It can
>>> connect over networks, but on mine it always seems to hang after
>>> an hour or so, and you have to kill it and restart it.
>>> That's a new one. Any other symptoms? Can you get a backtrace from a
>>> coredump?
>>>
>> The good news is I could not reproduce it. But when it happens again
>> I'll know who to notify.
>>
>> As I recall, the problem would occur in the query analyzer. If there
>> was highlighted text in the top window, and you highlighted a row in
>> the results, and then clicked into the upper window while dragging the
>> mouse, it would freeze the X server. It has happened much much less
>> often lately, but it did happen just two days ago, and it always
>> involves a click-drag situation.
>
> Yes, that seems a gtk issue. You mark, then klick accidentaly into
> the marked text (usually to change the mark area) and in the result
> you are dragging the text to nowhere. pgadmin and X freezes in this
> case. However you can login via another box and just kill pgadmin
> to unfreeze. Maybe there is a problem with how drag & drop
> is/isnt handled by the code? I have no idea.
It only happens in pgAdmin III, though, so it must be some strange
interaction between wxWindows and GTK. I believe that the window manager
is part of the problem too, because I've used KDE (together with kwin)
for the last few years, and while it had this freezing-problem
initially, it went away with some update. I believed that a wx or
pgadmin update solved this, but now I'm using Gnome (together with
metacity), and the problem is back... :-(

However, I figured out that if you press ALT-<key> with <key> being the
shortcut for some menu _directly_ after the freeze, the menu opens, and
the mouse pointer is restored back to it's normal shape... It won't work
if you click around after X freezes - I guess pgadminIII has to still
have the focus for this to work...

greetings, Florian Pflug


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Florian G. Pflug wrote:

> Tino Wildenhain wrote:
>
>> Kenneth Downs schrieb:
>>
>>> Dave Page wrote:
>>>
>>>> On my linux box, it also has the dubious honor of being the only
>>>> program I have ever seen that can lock X hard, with killing the X
>>>> server being the only rescue (if you call that a rescue). It can
>>>> connect over networks, but on mine it always seems to hang after
>>>> an hour or so, and you have to kill it and restart it.
>>>> That's a new one. Any other symptoms? Can you get a backtrace from
>>>> a coredump?
>>>>
>>> The good news is I could not reproduce it. But when it happens
>>> again I'll know who to notify.
>>>
>>> As I recall, the problem would occur in the query analyzer. If
>>> there was highlighted text in the top window, and you highlighted a
>>> row in the results, and then clicked into the upper window while
>>> dragging the mouse, it would freeze the X server. It has happened
>>> much much less often lately, but it did happen just two days ago,
>>> and it always involves a click-drag situation.
>>
>>
>> Yes, that seems a gtk issue. You mark, then klick accidentaly into
>> the marked text (usually to change the mark area) and in the result
>> you are dragging the text to nowhere. pgadmin and X freezes in this
>> case. However you can login via another box and just kill pgadmin
>> to unfreeze. Maybe there is a problem with how drag & drop
>> is/isnt handled by the code? I have no idea.
>
> It only happens in pgAdmin III, though, so it must be some strange
> interaction between wxWindows and GTK. I believe that the window manager
> is part of the problem too, because I've used KDE (together with kwin)
> for the last few years, and while it had this freezing-problem
> initially, it went away with some update. I believed that a wx or
> pgadmin update solved this, but now I'm using Gnome (together with
> metacity), and the problem is back... :-(
>
> However, I figured out that if you press ALT-<key> with <key> being the
> shortcut for some menu _directly_ after the freeze, the menu opens, and

Wow this is good to know.

I'm also glad to know I'm not the only person this is happening to.


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match