On 29 August 2017 at 05:15, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 8/28/17 15:11, Tom Lane wrote:
> >> ... but it seems like you're giving up a lot of the possible uses if
> >> you don't make it apply uniformly. I admit I'm not sure how we'd handle
> >> the initial creation of a conn
Peter Eisentraut writes:
> On 8/28/17 15:11, Tom Lane wrote:
>> ... but it seems like you're giving up a lot of the possible uses if
>> you don't make it apply uniformly. I admit I'm not sure how we'd handle
>> the initial creation of a connection object with a custom malloc. The
>> obvious solu
On 8/28/17 15:11, Tom Lane wrote:
> ... but it seems like you're giving up a lot of the possible uses if
> you don't make it apply uniformly. I admit I'm not sure how we'd handle
> the initial creation of a connection object with a custom malloc. The
> obvious solution of requiring the functions
On Mon, Aug 28, 2017 at 03:11:26PM -0400, Tom Lane wrote:
> Aaron Patterson writes:
> > I would like to be able to configure libpq with custom malloc functions.
>
> I can see the potential value of this ...
>
> > This patch doesn't replace all malloc calls to the configured ones, just
> > the ma
Aaron Patterson writes:
> I would like to be able to configure libpq with custom malloc functions.
I can see the potential value of this ...
> This patch doesn't replace all malloc calls to the configured ones, just
> the mallocs related to creating result objects (which is what I'm
> concerned
Hello!
I would like to be able to configure libpq with custom malloc functions.
The reason is that we have a Ruby wrapper that exposes libpq in Ruby.
The problem is that Ruby's GC doesn't know how much memory has been
allocated by libpq, so no pressure is applied to the GC when it should
be. Ruby
