On Wed, 2009-08-26 at 16:51 -0700, WANGRUNGVICHAISRI, SHIVESH wrote:
> However, I still insist that potentially the PostgreSQL community might
> want to look into why making use of libpq causes the client program's
> memory consumption to keep growing. This can be easily observed using
> the earlier test program uploaded to here:
I've looked into it ... and concluded I'm an idiot.
Your query is:
SELECT * FROM tmp WHERE id>615;
(where "615" could be any value < 1000)
For some reason I'd been thinking all along that the query was grabbing
*no* *more* *than* *1000* *rows* ... but of course it's not, it's
grabbing all but some lower fraction of the rows. So the result set gets
bigger and bigger over time until the program doesn't have enough RAM to
hold the result set and it crashes.
The attached (adjusted) test program no longer has any issues with
growth or runtime. There's no libpq issue here, only a
So, it seems we've eliminated any issue with leakage in the PostgreSQL
server backend, you've isolated your problem to PostGIS, and we've found
that the growth of the test program was libpq working as designed.
It looks like we're done here.
Description: text/x-makefile (490 bytes)
Description: text/x-c++src (3.9 KB)
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-08-27 02:48:40|
|Subject: Re: pretty print viewdefs |
|Previous:||From: Greg Stark||Date: 2009-08-27 02:35:52|
|Subject: Re: pretty print viewdefs|
pgsql-bugs by date
|Next:||From: Itagaki Takahiro||Date: 2009-08-27 03:59:18|
|Subject: BUG #5016: dlltool error in libecpg_compatdll.def|
|Previous:||From: Craig Ringer||Date: 2009-08-27 01:42:32|
|Subject: Re: BUG #5015: MySQL migration wizard does not start|