From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Cc: | postgres(at)cybertec(dot)at |
Subject: | RESET CONNECTION idea |
Date: | 2005-06-07 14:13:55 |
Message-ID: | 200506071413.j57EDtI01069@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Our current RESET CONNECTION TODO item is:
* Add RESET CONNECTION command to reset all session state
This would include resetting of all variables (RESET ALL), dropping of
temporary tables, removing any NOTIFYs, cursors, open transactions,
prepared queries, currval()s, etc. This could be used for connection
pooling. We could also change RESET ALL to have this functionality.
The difficult of this features is allowing RESET ALL to not affect
changes made by the interface driver for its internal use. One idea
is for this to be a protocol-only feature. Another approach is to
notify the protocol when a RESET CONNECTION command is used.
I know we have GUC variables that are passed automatically to the
client. I assume varaible changes are also automatically sent to the
client.
What if we create a 'reset_connection' guc that is initially false, and
is set to 'true' when someone resets a connection. Then, when it
happens, the client finds out, reconfigures whatever it needs, then sets
the value back to 'false'.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-06-07 14:53:58 | Request for support for GIST enhancements |
Previous Message | Oleg Bartunov | 2005-06-07 13:47:25 | GiST concurrency and recovery for 8.1 |