Re: Implementing RESET CONNECTION ...

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kris Jurka <books(at)ejurka(dot)com>, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, eg(at)cybertec(dot)at, pgsql-patches(at)postgresql(dot)org
Subject: Re: Implementing RESET CONNECTION ...
Date: 2005-01-04 01:20:44
Message-ID: 41D9EF6C.4000502@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Kris Jurka <books(at)ejurka(dot)com> writes:
>
>>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?

That doesn't really help the JDBC driver case. The problem is that there
are prepared statements that have been set up by the driver invisibly to
the user. Zapping them will make the driver break, and it's too easy for
the user code to do a full RESET CONNECTION and accidently zap them.

Yes, you can break the JDBC driver currently by doing explicit
DEALLOCATEs of its prepared statements -- but you have to do that quite
deliberately so it's less of a problem.

Having notification of either prepared statement deallocation or
connection reset (a la ParameterStatus for GUC changes) would help the
driver to recover from this case.

-O

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-01-04 01:27:44 Re: Implementing RESET CONNECTION ...
Previous Message Tom Lane 2005-01-04 00:56:53 Re: Implementing RESET CONNECTION ...

Browse pgsql-patches by date

  From Date Subject
Next Message Oliver Jowett 2005-01-04 01:25:33 Re: Implementing RESET CONNECTION ...
Previous Message Tom Lane 2005-01-04 01:03:29 Re: patch to add krb_server_hostname to postgresql.conf