Re: DISCARD ALL (Again)

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DISCARD ALL (Again)
Date: 2014-04-21 07:51:08
Message-ID: 5354CDEC.2030908@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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Ü

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Francois Tigeot 2014-04-21 09:26:43 Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Previous Message Hannu Krosing 2014-04-21 07:36:55 Re: DISCARD ALL (Again)