Thread: RESET SESSION
This is draft version, for discussion.
New commands:
CLOSE ALL
DEALLOCATE ALL
RESET PLANS
RESET TEMPS -- please suggest better name
RESET SESSION
So in the end RESET SESSION basically executes following commands:
ABORT;
DEALLOCATE ALL;
CLOSE ALL;
RESET ALL;
SET SESSION AUTHORIZATION DEFAULT;
UNLISTEN *;
RESET TEMPS;
RESET PLANS;
I think CLOSE ALL and DEALLOCATE ALL are useful in their own,
without considering poolers. They just make user lives easier.
The ALL just fits there.
RESET PLANS and RESET TEMPS are for the principle that components
for RESET SESSION should be available for users for special-case
situations and fine-tuning poolers. Also they add very little complexity.
(RESET PLANS could be useful its awn also).
Todo:
* Docs
* Disallow some commands inside TX?
* DEALLOCATE PREPARE ALL gives bison conflicts. is it needed?
* Send more details to client. Variants:
- CommandComplete: "RESET XXX", "CLOSE ALL", "DEALLOCATE ALL"
(CLOSE name and DEALLOCATE name would be good in normal case too,
that help anyone who wants to track what exists)
- RESET SESSION should send ParamStatus of all parms
--
marko
Attachment
"Marko Kreen" <markokr@gmail.com> writes:
> RESET TEMPS -- please suggest better name
RESET TEMP (should allow RESET TEMPORARY too). I see no reason to add
a new keyword when the existing one will do fine.
> So in the end RESET SESSION basically executes following commands:
> ABORT;
I object to having RESET SESSION include an ABORT. That will make it
a transaction control statement and complicate matters for a whole
lot of things. If you don't know whether you're in a transaction or
not, you can send ABORT for yourself, but in practice I think most
client code already tracks that (or easily can).
regards, tom lane
Tom Lane wrote: > "Marko Kreen" <markokr@gmail.com> writes: > > RESET TEMPS -- please suggest better name > > RESET TEMP (should allow RESET TEMPORARY too). I see no reason to add > a new keyword when the existing one will do fine. > > > So in the end RESET SESSION basically executes following commands: > > > ABORT; > > I object to having RESET SESSION include an ABORT. That will make it > a transaction control statement and complicate matters for a whole > lot of things. If you don't know whether you're in a transaction or > not, you can send ABORT for yourself, but in practice I think most > client code already tracks that (or easily can). It seems strange RESET SESSION would not terminate open transactions, but on the other hand calling RESET SESSION in a transaction seems odd too. I think we should at least throw an error if someone tries RESET SESSION inside a transaction, and hopefully administrators will realize they have a problem. Perhaps we can even offer a hint how to close open transactions. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> I object to having RESET SESSION include an ABORT.
> I think we should at least throw an error if someone tries RESET SESSION
> inside a transaction, and hopefully administrators will realize they
> have a problem.
PreventTransactionChain? Sure, if you like. Should the single-purpose
commands do that too?
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Tom Lane wrote: > >> I object to having RESET SESSION include an ABORT. > > > I think we should at least throw an error if someone tries RESET SESSION > > inside a transaction, and hopefully administrators will realize they > > have a problem. > > PreventTransactionChain? Sure, if you like. Should the single-purpose > commands do that too? No, I don't think so. RESET SESSION is something I expect people might get wrong, while the others I think are OK in transactions. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
Marko Kreen wrote:
> This is draft version, for discussion.
>
> New commands:
>
> CLOSE ALL
> DEALLOCATE ALL
> RESET PLANS
> RESET TEMPS -- please suggest better name
>
> RESET SESSION
>
> So in the end RESET SESSION basically executes following commands:
>
> ABORT;
> DEALLOCATE ALL;
> CLOSE ALL;
> RESET ALL;
> SET SESSION AUTHORIZATION DEFAULT;
> UNLISTEN *;
> RESET TEMPS;
> RESET PLANS;
>
>
> I think CLOSE ALL and DEALLOCATE ALL are useful in their own,
> without considering poolers. They just make user lives easier.
> The ALL just fits there.
>
> RESET PLANS and RESET TEMPS are for the principle that components
> for RESET SESSION should be available for users for special-case
> situations and fine-tuning poolers. Also they add very little complexity.
> (RESET PLANS could be useful its awn also).
>
> Todo:
>
> * Docs
> * Disallow some commands inside TX?
> * DEALLOCATE PREPARE ALL gives bison conflicts. is it needed?
> * Send more details to client. Variants:
> - CommandComplete: "RESET XXX", "CLOSE ALL", "DEALLOCATE ALL"
> (CLOSE name and DEALLOCATE name would be good in normal case too,
> that help anyone who wants to track what exists)
> - RESET SESSION should send ParamStatus of all parms
>
>
> --
> marko
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +