Re: Custom allocators in libpq

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Aaron Patterson <tenderlove(at)ruby-lang(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Custom allocators in libpq
Date: 2017-08-28 19:11:26
Message-ID: 17499.1503947486@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Aaron Patterson <tenderlove(at)ruby-lang(dot)org> 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 with).

... 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 to be specified at PQconnect
time seems to require Yet Another PQconnect Variant, which is not very
appetizing.

I also wonder whether you wouldn't want a passthrough argument.
For instance, one of the use-cases that springs to mind immediately is
teaching postgres_fdw and dblink to use this so that their result objects
are palloc'd not malloc'd, allowing removal of lots of PG_TRY overhead.
While I suppose we could have the hook functions always allocate in
CurrentMemoryContext, it'd likely be useful to be able to specify
"use context X" at creation time.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-08-28 19:26:58 Re: expanding inheritance in partition bound order
Previous Message Tom Lane 2017-08-28 19:00:02 Re: [HACKERS] [postgresql 10 beta3] unrecognized node type: 90