Re: Allow substitute allocators for PGresult. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allow substitute allocators for PGresult.
Date
Msg-id 1042.1321123761@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allow substitute allocators for PGresult.  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 11.11.2011 11:18, Kyotaro HORIGUCHI wrote:
>> For these reasons, I propose to make allocators for PGresult
>> replaceable.

> You could use the resource owner mechanism to track them.

BTW, I just thought of a potentially fatal objection to making PGresult
allocation depend on palloc: libpq is absolutely not prepared to handle
losing control on out-of-memory.  While I'm not certain that its
behavior with malloc is entirely desirable either (it tends to loop in
hopes of getting the memory next time), we cannot just plop in palloc
in place of malloc and imagine that we're not breaking it.

This makes me think that Heikki's approach is by far the more tenable
one, so far as dblink is concerned.  Perhaps the substitute-malloc idea
is still useful for some other application, but I'm inclined to put that
idea on the back burner until we have a concrete use case for it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Allow substitute allocators for PGresult.
Next
From: Kohei KaiGai
Date:
Subject: Re: [v9.2] Object access hooks with arguments support (v1)