RESET SESSION

Started by Marko Kreenover 19 years ago6 messagespatches
Jump to latest
#1Marko Kreen
markokr@gmail.com

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

Attachments:

session.reset.diffapplication/octet-stream; name=session.reset.diffDownload+152-10
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Marko Kreen (#1)
Re: RESET SESSION

"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

#3Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#2)
Re: RESET SESSION

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. +

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#3)
Re: RESET SESSION

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

#5Bruce Momjian
bruce@momjian.us
In reply to: Tom Lane (#4)
Re: RESET SESSION

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. +

#6Bruce Momjian
bruce@momjian.us
In reply to: Marko Kreen (#1)
Re: RESET SESSION

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. +