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
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 |