-------- Original Message --------
Subject: Re: [PATCHES] Implementing RESET CONNECTION ...
Date: Tue, 04 Jan 2005 13:58:44 +1300
From: Oliver Jowett <[EMAIL PROTECTED]>
To: Hans-Jürgen Schönig <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], firstname.lastname@example.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>
Hans-Jürgen Schönig wrote:
We have implemented a patch which can be used by connection pools for instance.
RESECT CONNECTION cleans up a backend so that it can be reused.
Perhaps this should be done at the protocol level (as a new message type), not as a SQL command, since it is dealing primarily with per-connection protocol state.
As Kris has mentioned elsewhere in the thread, things like the JDBC driver really don't want the connection state unexpectedly being changed under them by user queries (and go to some lengths to detect and complain about it if they do, e.g. by monitoring ParameterStatus messages).
If you do it at the protocol level, the semantics can be a bit more obvious: a reset packet resets the backend and protocol state to "as if just connected" state. Structure the reset packet like the initial startup packet; don't allow changing the user or database. So you get the same state as doing a disconnect/reconnect but presumably it is cheaper as you don't need to do authentication/fork/initialization.
If this does go in at the SQL command level, can we have a protocol-level notification that the connection has been reset please? The JDBC driver needs to notice the reset to continue to operate correctly after a reset. I can't see an obvious way to crowbar this into the current protocol unless we overload something like ParameterStatus which seems ugly.
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings