Re: [HACKERS] Custom allocators in libpq

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Custom allocators in libpq
Дата
Msg-id 17499.1503947486@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [HACKERS] Custom allocators in libpq  (Aaron Patterson <tenderlove@ruby-lang.org>)
Ответы Re: [HACKERS] Custom allocators in libpq  (Aaron Patterson <tenderlove@ruby-lang.org>)
Re: [HACKERS] Custom allocators in libpq  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
Aaron Patterson <tenderlove@ruby-lang.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] expanding inheritance in partition bound order