Re: Implementing RESET CONNECTION ... - Mailing list pgsql-patches

From Tom Lane
Subject Re: Implementing RESET CONNECTION ...
Date
Msg-id 11856.1104800213@sss.pgh.pa.us
Whole thread Raw
In response to Re: Implementing RESET CONNECTION ...  (Kris Jurka <books@ejurka.com>)
Responses Re: Implementing RESET CONNECTION ...  (Oliver Jowett <oliver@opencloud.com>)
List pgsql-patches
Kris Jurka <books@ejurka.com> writes:
> On Thu, 30 Dec 2004, [ISO-8859-1] 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. Temp tables, LISTEN / NOTIFY stuff, WITH HOLD cursors, open
>> transactions, prepared statements and GUCs are cleaned up. I hope we
>> have not missed important per-backend information.

> From the JDBC driver's perspective this doesn't meet the needs I'd like to
> see in a connection reset.  In the initial connection setup a number of
> GUC variables are tweaked to what the JDBC driver desires (DateStyle,
> client_encoding).  When resetting we'd want to reset to this point, not
> the default values.

I haven't looked at the proposed patch, but I would've expected that it
duplicates the existing RESET ALL behavior for GUC settings.  And that
already works the way you want.  Values taken from the client connection
request packet establish the session defaults, ie, what RESET goes to.

> Also I don't like the idea of cleaning up prepared statements.

Hmm.  This seems a bit eye-of-the-beholder-ish, ie you could make a
legitimate argument either way.  Maybe the RESET CONNECTION command
should have an option whether to zap prepared statements or not?
Is there anything else falling in the category of "debatable"?

            regards, tom lane

pgsql-patches by date:

Previous
From: lsunley@mb.sympatico.ca
Date:
Subject: Re: psql session log
Next
From: lsunley@mb.sympatico.ca
Date:
Subject: logfile for psql patch update