Re: DISCARD ALL (Again)

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: DISCARD ALL (Again)
Дата
Msg-id 5354CDEC.2030908@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: DISCARD ALL (Again)  ("Joshua D. Drake" <jd@commandprompt.com>)
Список pgsql-hackers
On 04/18/2014 06:44 PM, Joshua D. Drake wrote:
>
> On 04/18/2014 08:01 AM, Peter Eisentraut wrote:
>>
>> On 4/17/14, 4:44 PM, Joshua D. Drake wrote:
>>> That we should also release the GD?
>>
>> In some cases, SD or GD are used to cache things.  Having the connection
>> pooler blow that away would defeat the point.
>
> Not on a per session basis. Although I can see your point.
> The GD is supposed to be global per session.
> If, I discard the session to it's original state, that is going to
> predate the creation of the GD. That is expected behavior.
The reason (I assume) you want DISCARD ALL instead of reconnect is
performance.

Often stuff (like another connection) is cached in GD also for performance.

Another things I sometimes do in pl/pythonu is add my own functions to
__builtins__
and also use pl/python functions as modules by having some "global"
state in definitions.

The only way to automatically reset all that would be complete reset of
interpreter (as Tom mentioned above)

For these reasons I suggest that the cleanest way to achieve "discard
all" for pl/python
would be ability to register a clean-up function and not trying to
second-guess what
global cached state *might* exists.


Cheers

-- 
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ




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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: DISCARD ALL (Again)
Следующее
От: Francois Tigeot
Дата:
Сообщение: Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD