Re: Memory for BYTEA returned by C function is not released until connection is dropped - Mailing list pgsql-general

From John Leiseboer
Subject Re: Memory for BYTEA returned by C function is not released until connection is dropped
Date
Msg-id 1EC7FC2A429FF940B43E21AC8D1EECD057F53D66@qbrick.homeip.net
Whole thread Raw
In response to Re: Memory for BYTEA returned by C function is not released until connection is dropped  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane [mailto:tgl@sss.pgh.pa.us] writes:
> But at any rate, bottom line is that your problem is client-side not server-side, and no amount of fooling with the
functioninnards will change it. 

I wish it were. While monitoring memory on Linux and Windows machines I see that psql memory usage hardly changes, but
PostgreSQLserver memory usage increases steadily until the query stops. PostgreSQL server memory usage stays high until
afterthe client drops the connection. This is definitely a case of the server holding onto memory until the client
dropsthe connection. 

In other case, when I let the query continue until memory is exhausted, the PostgreSQL server crashes with "out of
memory"error, not the client. 

When does the PostgreSQL server call pfree() after a C function has returned to the caller? All I've found in books and
Googlesearches is: 

"What makes palloc() special is that it allocates the memory in the current context and the whole memory is freed in
onego when the context is destroyed." 

What "context"? The connection? The transaction? A SQL statement? The function call?

John


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Memory for BYTEA returned by C function is not released until connection is dropped
Next
From: Etienne Champetier
Date:
Subject: looking for old rpm