On 5 October 2010 10:20, Dave Page <dpage@pgadmin.org> wrote:
> On Fri, Oct 1, 2010 at 2:32 PM, Thom Brown <thom@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.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935