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: 4EBCEAFA.6010507@enterprisedb.com (view raw or flat)
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: http://archives.postgresql.org/pgsql-hackers/1999-02/msg00364.php
>
> 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 
released.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

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-2014 The PostgreSQL Global Development Group