Re: Path to enable a module to change the stack_base_ptr

Поиск
Список
Период
Сортировка
От Thomas Hallgren
Тема Re: Path to enable a module to change the stack_base_ptr
Дата
Msg-id thhal-0kjoqBFci8rQOzcIPlvH8oxLpABtbBf@mailblocks.com
обсуждение исходный текст
Ответ на Re: Path to enable a module to change the stack_base_ptr  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-patches
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
>>> Tom Lane wrote:
>>>
>>>> I'm not really in favor of this ... I think you are trying to make the
>>>> backend do something that will never work reliably.
>>>>
>
>
>> Do we want to make this change for 8.1?
>>
>
> I don't want to do it at all.  The justification given is to allow the
> backend to support multithreading introduced by an add-on library, which
> is a hopeless cause.  Removing "static" from that variable declaration
> is surely a cheap enough change, but what about the next request, and
> the one after that?
>
Tom, I don't request that the backend should support multiple threads
simultaneously. It's one thread at a time. I can't think of a "next
request" in this direction. I'm very aware that the backend is
single-threaded and that you have no intention to change that. Neither do I.

Having the stack_base public is actually useful for another purpose
also. It can allow you to make assertions that check if an abitrary
pointer is 'on stack' or not. The MemoryContextContains() could be made
safer too by just returning false when the given pointer is between the
stack_base and the current stack_pointer. Perhaps that could be added to
the patch?

Regards,
Thomas Hallgren



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Make 2PC error messages match docs
Следующее
От: Michael Fuhr
Дата:
Сообщение: Re: Documentation typos