I have backed out the patch until there is more discussion.
I now see that the CC list had an incorrect entry for the patches list,
so I am unsure if others have seen this patch thoroughly.
---
Hans-J?rgen Sch?nig wrote:
>
Attached patch applied, with slight modifications. Thanks.
---
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
Christopher Kings-Lynne wrote:
What would be absolutely ideal is a reset connection command, plus some
way of knowing via the protocol if it's needed or not.
And a way of notifying the client that a reset has happened.
-O
---(end of broadcast)--
What would be absolutely ideal is a reset connection command, plus some
way of knowing via the protocol if it's needed or not.
Chris
Bruce Momjian wrote:
What did we decide on RESET CONNECTION. Do we want an SQL command or
something only the protocol can do?
-
What did we decide on RESET CONNECTION. Do we want an SQL command or
something only the protocol can do?
---
Oliver Jowett wrote:
> (cc'ing -hackers)
>
> Karel Zak wrote:
>
> > I think command status is common and nice fe
Bruce Momjian writes:
> Hans-Jürgen Schönig wrote:
>> I completely agree with Karel. I think it is a bad idea to change the
>> protocol for such a minor feature - i tend to call it overkill.
> I think autocommit is a good example for comparison.
Indeed, it is an *excellent* example for comparis
Bruce Momjian wrote:
Hans-Jïrgen Schïnig wrote:
I completely agree with Karel. I think it is a bad idea to change the
protocol for such a minor feature - i tend to call it overkill.
I want to add one point to this discussion: There is not just JDBC -
other connection pools or clients might want d
Hans-Jürgen Schönig wrote:
> I completely agree with Karel. I think it is a bad idea to change the
> protocol for such a minor feature - i tend to call it overkill.
> I want to add one point to this discussion: There is not just JDBC -
> other connection pools or clients might want different beha
(cc'ing -hackers)
Karel Zak wrote:
I think command status is common and nice feedback for client. I think
it's more simple change something in JDBC than change protocol that is
shared between more tools.
There is a bit of a queue of changes that would be nice to have but
require a protocol version
On Wed, 2005-01-05 at 01:33 +1300, Oliver Jowett wrote:
> Karel Zak wrote:
> > I think each PG command returns some status. For example in libpq it's
> > possible check by PQcmdStatus(). I think JDBC can checks this status (by
> > own PQcmdStatus() implementation) and if PG returns string "CONNECTI
Hans-Jürgen Schönig wrote:
If the JDBC driver prefers different behaviour (maybe for prepared
statements) we should discuss further options for RESET.
Now there is: RESET CONNECTION (cleaning entire connection), RESET ALL
(cleaning GUCS only) and RESET some_guc.
Maybe we want RESET LISTENER, RESE
Karel Zak wrote:
I still don't see a big difference between DEALLOCATE and RESET -- both
can break the JDBC driver.
You have to go out of your way to break the driver via DEALLOCATE,
explicitly finding a statement name that the driver is using. There's
also a reasonably simple fix: make the proto
On Tue, 4 Jan 2005, [ISO-8859-1] Hans-Jürgen Schönig wrote:
> I completely agree with Karel. I think it is a bad idea to change the
> protocol for such a minor feature - i tend to call it overkill.
I agree. I don't think it's imperative to prevent or detect this
condition. The only real cal
I completely agree with Karel. I think it is a bad idea to change the
protocol for such a minor feature - i tend to call it overkill.
I want to add one point to this discussion: There is not just JDBC -
other connection pools or clients might want different behaviour (which
can from my point of
On Mon, 2005-01-03 at 20:27 -0500, Tom Lane wrote:
> I'm inclined to think that we'd have to add a protocol message that
> reports RESET CONNECTION to really answer objections of this type.
> That seems to bring the thing into the category of "stuff that forces
> a protocol version bump" :-(
>
>
Tom Lane wrote:
Fair point, but you could make the same argument against *any* side
effect of RESET CONNECTION. You're just complaining about PREPARE
because you can see immediately where that breaks JDBC. Anything that
any driver does to set up per-connection state the way it wants will
be equal
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 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 d
Tom Lane wrote:
Kris Jurka <[EMAIL PROTECTED]> 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 prepare
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 <[EMAIL PROTECTED]&
Kris Jurka <[EMAIL PROTECTED]> 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 HOL
On Mon, 3 Jan 2005, [UTF-8] Hans-JÃrgen SchÃnig wrote:
> I have seen that the JDBC driver is doing some GUC settings.
> However, this does not prevent you from bad users who change GUCs for
> some reason.
Actually it does. The V3 protocol provides a ParameterStatus message that
notifies us wh
Kris,
I have seen that the JDBC driver is doing some GUC settings.
However, this does not prevent you from bad users who change GUCs for
some reason. It might very well happen that a user sets the DateStyle to
some different value temporarily. A different program would in this case
behave RANDOM
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
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 importan
24 matches
Mail list logo
