Re: DISCARD ALL (Again) - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: DISCARD ALL (Again)
Date
Msg-id 5354CDEC.2030908@2ndQuadrant.com
Whole thread Raw
In response to Re: DISCARD ALL (Again)  ("Joshua D. Drake" <jd@commandprompt.com>)
List 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 by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: DISCARD ALL (Again)
Next
From: Francois Tigeot
Date:
Subject: Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD