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
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 ... |
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 |