I just looked at the code in the close() method and all it is doing is
closing the socket connection to the server. However in looking at the
doc on the backend/frontend protocol it appears that the client (JDBC in
this case) is supposed to send a connection termination message first,
then close the socket. I beleive that the termination message is
supposed to be a one byte value of 'X'. If I read this correctly, then
it does appear that the JDBC connection class does have a bug.
Alexander Jerusalem wrote:
> At 21:40 22.01.01, Peter Mount wrote:
> >At 13:18 21/01/01 +0100, Alexander Jerusalem wrote:
> >>Hi all,
> >>I'm experiencing some strange behaviour with postgresql 7.0.3 on Red Hat
> >>Linux 7. I'm sending lots of insert statements to the postgresql server
> >>>from another machine via JDBC. During that process postgresql continues to
> >>take up more and more memory and seemingly never returns it to the
> >>system. Oddly if I watch the postmaster and it's sub processes in ktop, I
> >>can't see which process takes up this memory. ktop shows that the
> >>postgresql related processes have a constant memory usage but the overall
> >>memory usage always increases as long as I continue to send insert statements.
> >>When the database connection is closed, no memory is reclaimed, the
> >>overall memory usage stays the same. And when I close down all postgresql
> >>processes including postmaster, it's the same.
> >>I'm rather new to Linux and postgresql so I'm not sure if I should call
> >>this a memory leak :-)
> >>Has anybody experienced a similar thing?
> >I'm not sure myself. You can rule out JDBC (or Java) here as you say you
> >are connecting from another machine.
> >When your JDBC app closes, does it call the connection's close() method?
> >Does any messages like "Unexpected EOF from client" appear on the server side?
> >The only other thing that comes to mine is possibly something weird is
> >happening with IPC. After you closed down postgres, does ipcclean free up
> >any memory?
> >I'm cc'in the hackers list and the new jdbc list.
> Thanks for your answer!
> Yes I'm calling Connection.close(). I don't get any error messages but
> maybe I just don't see them because postgresql is started automatically at
> run level 3. I'm not sure where the output goes. (pg_log contains only
> garbage or maybe it's a binary file) I tried ipcclean right now and it
> doesn't free the memory but it gives me some messages that I cannot interpret:
> Shared memory 0 ... skipped. Process still exists (pid ).
> Shared memory 1 ... skipped. Process still exists (pid ).
> Shared memory 2 ... skipped. Process still exists (pid ).
> Shared memory 3 ... skipped. Process still exists (pid ).
> Semaphore 0 ... resource(s) deleted
> Semaphore 1 ... resource(s) deleted
> Oddly, when I try to run ipcclean a second time, it says: ipcclean: You
> still have a postmaster running. Which is not the case as ps -e proves.
> Alexander Jerusalem
In response to
pgsql-hackers by date
|Next:||From: Tatsuo Ishii||Date: 2001-01-23 01:04:12|
|Subject: Re: A Patch for MIC to EUC_TW code converting in mb
|Previous:||From: Alexander Jerusalem||Date: 2001-01-22 23:58:49|
|Subject: Re: [HACKERS] Re: postgres memory management|
pgsql-jdbc by date
|Next:||From: Justin Clift||Date: 2001-01-23 02:03:58|
|Subject: Re: postgres memory management|
|Previous:||From: The Hermit Hacker||Date: 2001-01-23 00:38:52|
|Subject: testing ...|
pgsql-general by date
|Next:||From: Bruce Momjian||Date: 2001-01-23 00:49:58|
|Subject: Re: OID/XID allocation (was Re: is PG able to handle a >500 GB Da tabase?)|
|Previous:||From: Mikheev, Vadim||Date: 2001-01-23 00:44:04|
|Subject: RE: OID/XID allocation (was Re: is PG able to handle a >500 GB Database?)|