Re: DISCARD ALL (Again)

From: David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DISCARD ALL (Again)
Date: 2014-04-18 02:18:03
Message-ID: CAKFQuwZ49gLV-OQVjS=-5d5v4tPWq=XQ9rgBHCGuuKeechhosg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, April 17, 2014, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:

>
> On 04/17/2014 07:07 PM, David G Johnston wrote:
>
>>
>> On 04/17/2014 05:24 PM, Tom Lane wrote:
>> > On the whole I'm not sure this is something we ought to get into.
>> > If you really need a fresh session, maybe you should start a
>> > fresh session.
>>
>>
>> Isn't the whole point to avoid the reconnection overhead, especially for
>> connection poolers? DISCARD ALL shouldn't cause any cleanup that
>> wouldn't otherwise occur when a session disconnects. True global data
>> (not just session global) should be excluded.
>>
>
> The GD is global to the session only (Like temp tables).

Yes. Tom's response makes it sound like the proposal is to throw away the
entire language environment for the whole server (thus needing super user
privilege) so I'm pointing out that what we are discussing is not that
invasive.

>
>
>> A better wording of the promise would be: "discard all" leaves the
>> session in the same state it would be in if the underlying connection
>> were dropped and re-established.
>>
>
> Except that it doesn't.
>
>
But is this what you intend it to mean, by implementing these features, or
are you thinking something different?

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-04-18 03:21:05 Re: assertion failure 9.3.4
Previous Message Stephen Frost 2014-04-18 02:15:15 Re: DISCARD ALL (Again)