Skip site navigation (1) Skip section navigation (2)

Re: Allow substitute allocators for PGresult.

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Allow substitute allocators for PGresult.
Date: 2011-11-11 09:29:30
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On 11.11.2011 11:18, Kyotaro HORIGUCHI wrote:
> The comment at the the begging of pqexpbuffer.c says that libpq
> should not rely on palloc(). Besides, Tom Lane said that palloc
> should not be visible outside the backend(*1) and I agree with
> it.
> *1:
> On the other hand, in dblink, dblink-plus (our product!), and
> maybe FDW's connect to other PostgreSQL servers are seem to copy
> the result of the query contained in PGresult into tuple store. I
> guess that this is in order to avoid memory leakage on
> termination in halfway.
> But it is rather expensive to copy whole PGresult, and the
> significance grows as the data received gets larger. Furthermore,
> it requires about twice as much memory as the net size of the
> data. And it is fruitless to copy'n modify libpq or reinvent it
> from scratch. So we shall be happy to be able to use palloc's in
> libpq at least for PGresult for such case in spite of the policy.
> For these reasons, I propose to make allocators for PGresult
> replaceable.

You could use the resource owner mechanism to track them. Register a 
callback function with RegisterResourceReleaseCallback(). Whenever a 
PGresult is returned from libpq, add it to e.g a linked list, kept in 
TopMemoryContext, and also store a reference to CurrentResourceOwner in 
the list element. In the callback function, scan through the list and 
free all the PGresults associated with the resource owner that's being 

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2011-11-11 11:55:53
Subject: Re: Adding Node support in outfuncs.c and readfuncs.c
Previous:From: YAMAMOTO TakashiDate: 2011-11-11 09:26:53
Subject: Re: reduce null bitmap size

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group