On 5 October 2010 11:03, Thom Brown <t...@linux.com> wrote:
> On 5 October 2010 10:20, Dave Page <dp...@pgadmin.org> wrote:
>> On Fri, Oct 1, 2010 at 2:32 PM, Thom Brown <t...@linux.com> wrote:
>>> 2010-10-01 13:37:13 BST LOG     unexpected EOF on client connection
>>> 2010-10-01 13:37:12 BST LOG     could not receive data from client: No
>>> connection could be made because the target machine actively refused
>>> it.
>>>
>>> This was just before I noticed the massive memory usage.  I took the
>>> screenshot at 13:42.
>>
>> I chatted with Guillaume about this, and we don't currently see how it
>> could happen (clearly it did, but...). If you can figure out a way to
>> reproduce, that would be a huge help.
>
> Okay, I've tried reproducing it by asking it to show the edit view
> without restricting the number of results, but seems to be fine.  But
> if I open with limited to 100, then change it to "no limit", refresh
> and close, the query still appears to be running on the server.  It
> shows "pgAdmin III - Edit Grid" as the process running the query too,
> and there's still lots of I/O on the machine.  I definitely don't
> still have that window open.
>
> At this point it hasn't received any results back, so the memory usage
> hasn't peaked yet.  A postgres process has, however, has over 2GB of
> read I/O, bearing in mind I've only used it very little today.  ...
> and has now reached 3GB as I'm writing this.
>
> I've had to kill of pgAdmin III now since it stopped responding, even
> though the memory usage hadn't gone up.  Postgres still appears to be
> busy collecting the results.
>
> Tried it again, and exactly the same problem.  Only happens when
> initially opening the edit view with 100 rows and updating it to have
> no limit, then closing it before results come back.
>
> And now another table which can't return results back straight away,
> but would still return them after a short wait... same problem, and
> pgAdmin III is bloating.  It's reached 200MB and rising.

Another note, pgAdmin III returns to normal memory usage once all
results have been "received".  But if you're selecting from a 100GB
table by accident, that's not really a consolation. ;)

-- 
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

-- 
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

Reply via email to