Re: Implementing RESET CONNECTION ...

Resending to the correctly-spelled list alias. Why does postgresql.org
not generate bounces for unknown addresses, anyway?

-------- Original Message --------
Subject: Re: [PATCHES] Implementing RESET CONNECTION ...
Date: Tue, 04 Jan 2005 13:58:44 +1300
From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
CC: pgsql-patche(at)postgresql(dot)org, pgman(at)candle(dot)pha(dot)pa(dot)us,
eg(at)cybertec(dot)at, books(at)ejurka(dot)com
References: <41D3F834(dot)9090706(at)cybertec(dot)at>

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.

-O