Re: pgsql: Remove inappropriate memory context switch in

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: pgsql: Remove inappropriate memory context switch in
Дата
Msg-id
13281.1228086429@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
pgsql: Remove inappropriate memory context switch in tgl@postgresql.org (Tom Lane)
Re: pgsql: Remove inappropriate memory context switch in "Neil Conway" <neilc@samurai.com>
Re: pgsql: Remove inappropriate memory context switch in Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Remove inappropriate memory context switch in "Neil Conway" <neilc@samurai.com>
Re: pgsql: Remove inappropriate memory context switch in Tom Lane <tgl@sss.pgh.pa.us>
Re: pgsql: Remove inappropriate memory context switch in Tom Lane <tgl@sss.pgh.pa.us>
"Neil Conway"  writes:
> ... I think better would be to figure out a more appropriate
> memory context to switch into before deleting the multi-call context.

BTW, I did look at that alternative.  In principle we could have
init_MultiFuncCall save the current context and let end_MultiFuncCall
switch to that context.  However there are a couple of serious problems
with that:

1. There's noplace in FuncCallContext to save it.  Adding a field would
represent an ABI break that is certain to break external modules, so
it seems a nonstarter for a back-patchable fix.

2. We can't be absolutely sure that this is the right context to return
to anyway --- perhaps the SRF changed the context before calling
init_MultiFuncCall.  (One plausible mechanism for this is if SPI_connect
is called first.)  SRF_RETURN_DONE() doesn't give the caller any chance
to fix things afterwards, so a 95% or 99% solution isn't good enough.

In general, I think funcapi.c has no business making a change to the
caller's CurrentMemoryContext in any case.  It never did so before the
February patch, and is not documented to do so.

			regards, tom lane
В списке pgsql-committers по дате отправления
От: Tom Lane
Дата:
От: tgl@postgresql.org (Tom Lane)
Дата:
FAQ