On Tue, Nov 23, 2010 at 2:33 AM, Kris Jurka wrote:
>
>
> On Mon, 22 Nov 2010, Itagaki Takahiro wrote:
>
>> On Fri, Oct 15, 2010 at 03:40, Rados?aw Smogura
>> wrote:
Regarding JDBC in the CF process -- other interfaces are handled
there. I haven't seen one patch this size for JDBC
On Mon, 22 Nov 2010, Itagaki Takahiro wrote:
On Fri, Oct 15, 2010 at 03:40, Rados?aw Smogura
wrote:
Regarding JDBC in the CF process -- other interfaces are handled
there. I haven't seen one patch this size for JDBC since I've been
involved, let alone two competing patches to implement the
On Fri, Oct 15, 2010 at 03:40, Radosław Smogura
wrote:
>> Regarding JDBC in the CF process -- other interfaces are handled
>> there. I haven't seen one patch this size for JDBC since I've been
>> involved, let alone two competing patches to implement the same
>> feature. Small patches which can
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > why would we do this client-side rather than server-side?
>
> Because the timeout is supposed to be a limit on the time allowed
> for specific Java methods to complete, which might be running a
> large number of SQL statements within one invoc
Bruce Momjian wrote:
> why would we do this client-side rather than server-side?
Because the timeout is supposed to be a limit on the time allowed
for specific Java methods to complete, which might be running a
large number of SQL statements within one invocation, and which may
include signifi
Tom Lane wrote:
> Bruce Momjian writes:
> >> Tom Lane wrote:
> >>> I'm all for doing this client-side.
>
> > Uh, why would we do this client-side rather than server-side? If we do
> > it server-side, all interfaces get it.
>
> 1. The API that's being implemented is JDBC-specific.
>
> 2. Even
Bruce Momjian writes:
>> Tom Lane wrote:
>>> I'm all for doing this client-side.
> Uh, why would we do this client-side rather than server-side? If we do
> it server-side, all interfaces get it.
1. The API that's being implemented is JDBC-specific.
2. Even if you want to argue that it would b
Kevin Grittner wrote:
> Tom Lane wrote:
>
> > I'm all for doing this client-side.
>
> Well, that makes a big difference. Unless someone can make a
> convincing argument for why we should modify the server side to
> support this, I think we should just focus on this one client-side
> patch.
>
On 15/10/2010 10:38 PM, Tom Lane wrote:
Yeah, actually what you need is DISCARD ALL when reassigning a
connection to another client. Anything less than that assumes the
clients are cooperating closely, ie they *want* the same prepared
statements etc.
For what it's worth, this is quite common
Stephen Frost writes:
> IOW, yeah, you're right, the role doesn't really matter. One thing that
> occurs to me when I last ran into a problem with this- it was painful to
> debug because the "permission denied" error didn't indicate which schema
> the table it was trying to access was in. I wond
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> >> The whole problem with search_path and role is very frustrating. We've
> >> taken to just hacking things to be dynamic SQL whenever it's
> >> role-specific, but that's a really poor solution. I wonder if it would
> >> be possibl
Stephen Frost writes:
>> The whole problem with search_path and role is very frustrating. We've
>> taken to just hacking things to be dynamic SQL whenever it's
>> role-specific, but that's a really poor solution. I wonder if it would
>> be possible to have the function and prepare'd plan caches
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
[... much useful info ...]
Thanks for all of that, I certainly appreciate it.
> By default pgbouncer maintains a different pool per database and role,
> so you should be partly covered here.
No, not really.. We have a single unprivile
Stephen Frost writes:
> That assumption is certainly something I feel we should consider a valid
> and important use-case. I'd think a lot of the time your typical website
> is going to be using a dedicated pooler for connections and a dedicated
> database where having those queries cache'd would
Tom Lane wrote:
> I'm all for doing this client-side.
Well, that makes a big difference. Unless someone can make a
convincing argument for why we should modify the server side to
support this, I think we should just focus on this one client-side
patch.
I'd be happy to give it a closer look
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > errr, I don't believe RESET ALL touches cache'd plans and whatnot (which
> > is actually a problem I've run into in the past, because changing the
> > search_path also doesn't invalidate plans, and neither does set role, so
> > you
Stephen Frost writes:
> * RadosÅaw Smogura (rsmog...@softperience.eu) wrote:
>> But benefits of pooling statements are much more greater then RESET ALL,
>> because you can take advance of precompiling prepared statements,
>> increasing performance; it is comparable to using connection pool instea
=?UTF-8?Q?Rados=C5=82aw_Smogura?= writes:
> On Fri, 15 Oct 2010 10:37:05 +0200, Magnus Hagander
> wrote:
>>> But... connection pooler will not send RESET ALL in some situations,
>> To me, that sounds like a bug in the connection pooler. It is only
>> safe under quite limited circumstances.
> It
* Radosław Smogura (rsmog...@softperience.eu) wrote:
> > To me, that sounds like a bug in the connection pooler. It is only
> > safe under quite limited circumstances.
>
> It's hard to say this is bug. The GF connection pooler is "general pooler"
> for all drivers, so it can't know anything about
On Fri, 15 Oct 2010 10:37:05 +0200, Magnus Hagander
wrote:
>> But... connection pooler will not send RESET ALL in some situations,
>> because JDBC driver can have no notify about switching client. In EE
>> platforms (e. g. Glassfish), server sometimes creates it's own pool and
>> in
>> certain con
On Fri, Oct 15, 2010 at 08:56, Radosław Smogura
wrote:
> On Tue, 12 Oct 2010 20:03:29 +0200, Magnus Hagander
> wrote:
>> On Tue, Oct 12, 2010 at 17:55, David Fetter wrote:
>>> On Tue, Oct 12, 2010 at 10:37:00AM -0500, Kevin Grittner wrote:
David Fetter wrote:
> Is there something inco
On Tue, 12 Oct 2010 20:03:29 +0200, Magnus Hagander
wrote:
> On Tue, Oct 12, 2010 at 17:55, David Fetter wrote:
>> On Tue, Oct 12, 2010 at 10:37:00AM -0500, Kevin Grittner wrote:
>>> David Fetter wrote:
>>> > Is there something incomplete about the ones I sent, and if so,
>>> > what?
>>>
>>> Wel
"Kevin Grittner" writes:
> Robert Haas wrote:
>> I thought we had decided on the client-side approach, but maybe
>> I'm confused. I don't have a position one way or the other, just
>> trying to understand the state of the conversation.
> Well, I've been pretty vocal on supporting a client-side
> Regarding JDBC in the CF process -- other interfaces are handled
> there. I haven't seen one patch this size for JDBC since I've been
> involved, let alone two competing patches to implement the same
> feature. Small patches which can be quickly handled don't make sense
> to put into the proces
Robert Haas wrote:
Kevin Grittner wrote:
> I thought we had decided on the client-side approach, but maybe
> I'm confused. I don't have a position one way or the other, just
> trying to understand the state of the conversation.
Well, I've been pretty vocal on supporting a client-side solution
On Thu, Oct 14, 2010 at 08:22:21AM -0400, Robert Haas wrote:
> On Thu, Oct 14, 2010 at 2:59 AM, Radosław Smogura
> wrote:
> > On Wed, 13 Oct 2010 21:01:06 -0400, Robert Haas
> > wrote:
> >> Is this a JDBC patch or a PG patch? Are we tracking JDBC patches
> >> using the CF app?
> >
> > It is JDBC
On Thu, Oct 14, 2010 at 8:55 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Is this a JDBC patch or a PG patch? Are we tracking JDBC patches
>> using the CF app?
>
> If this were the only patch for setQueryTimeout in front of us I
> probably wouldn't have suggested that, but this thread star
Robert Haas wrote:
> Is this a JDBC patch or a PG patch? Are we tracking JDBC patches
> using the CF app?
If this were the only patch for setQueryTimeout in front of us I
probably wouldn't have suggested that, but this thread started with a
patch proposal to implement the same JDBC feature thr
On Thu, Oct 14, 2010 at 2:59 AM, Radosław Smogura
wrote:
> On Wed, 13 Oct 2010 21:01:06 -0400, Robert Haas
> wrote:
>> Is this a JDBC patch or a PG patch? Are we tracking JDBC patches
>> using the CF app?
>
> It is JDBC patch. I will clean it and submit on this site. I didn't know
> about such a
On Wed, Oct 13, 2010 at 2:27 PM, Kevin Grittner
wrote:
> Rados*aw Smogura wrote:
>
>> I updated patch to latets CVS version, I didn't have time to
>> remove some trashes from it.
>>
>> If something will be wrong with patch, give a feedback.
>
> I skimmed it and agree that it is the right general a
On Wed, 13 Oct 2010 21:01:06 -0400, Robert Haas
wrote:
> Is this a JDBC patch or a PG patch? Are we tracking JDBC patches
> using the CF app?
It is JDBC patch. I will clean it and submit on this site. I didn't know
about such application and such process.
--
Radosław Smogura
http://www.
Rados*aw Smogura wrote:
> I updated patch to latets CVS version, I didn't have time to
> remove some trashes from it.
>
> If something will be wrong with patch, give a feedback.
I skimmed it and agree that it is the right general approach --
using java.util.Timer to trigger the cancel method.
This, what I see in your patch, is sending additional statement to server.
This adds some unnecessery (especially TCP/IP) latency. gura
> > I sent such patch fully in Java
> > (http://archives.postgresql.org/pgsql-jdbc/2009-11/msg00010.php),
> > implementing cancellation with Timer and "cancel q
David Fetter writes:
> Let's imagine you have a connection pooler with two clients, A and B.
> A calls setQueryTimeout, then starts a query, which terminates in
> time, but dies before handling it. B connects to the pool, gets A's
> connection, and finds a statement_timeout that's not the default
On Tue, Oct 12, 2010 at 17:55, David Fetter wrote:
> On Tue, Oct 12, 2010 at 10:37:00AM -0500, Kevin Grittner wrote:
>> David Fetter wrote:
>> > Is there something incomplete about the ones I sent, and if so,
>> > what?
>>
>> Well, I'm still curious why it was necessary to modify the server
>> si
David Fetter wrote:
> Let's imagine you have a connection pooler with two clients,
> A and B.
I'm with you so far.
> A calls setQueryTimeout, then starts a query, which terminates in
> time, but dies before handling it.
Here you lost me. I don't know what that means.
> B connects to the
On Tue, Oct 12, 2010 at 10:37:00AM -0500, Kevin Grittner wrote:
> David Fetter wrote:
> > Is there something incomplete about the ones I sent, and if so,
> > what?
>
> Well, I'm still curious why it was necessary to modify the server
> side to implement an interface feature for which everything
David Fetter wrote:
> Is there something incomplete about the ones I sent, and if so,
> what?
Well, I'm still curious why it was necessary to modify the server
side to implement an interface feature for which everything needed
seems to be present on the client side. Is this intended to be
use
On Tue, Oct 12, 2010 at 04:04:56AM -0500, Radosław Smogura wrote:
> On Mon, 11 Oct 2010 08:29:16 -0500, "Kevin Grittner"
> wrote:
> > David Fetter wrote:
> >
> >> Please find enclosed a WIP patch from one of my co-workers
> >> intended to support JDBC's setQueryTimeout, along with the patch
> >
On Mon, 11 Oct 2010 08:29:16 -0500, "Kevin Grittner"
wrote:
> David Fetter wrote:
>
>> Please find enclosed a WIP patch from one of my co-workers
>> intended to support JDBC's setQueryTimeout, along with the patch
>> for JDBC that uses it.
>
> I agree that it would be very nice to support thi
Magnus Hagander writes:
> On Mon, Oct 11, 2010 at 16:17, Tom Lane wrote:
>> ... and, if you are seriously expecting to have that happen, why the
>> patch was submitted to pgsql-jdbc not pgsql-hackers?
> To be fair to David, it was sent to *both* pgsql-jdbc and
> pgsql-hackers. Maybe it was held
On Mon, Oct 11, 2010 at 16:17, Tom Lane wrote:
> "Kevin Grittner" writes:
>> David Fetter wrote:
>>> Please find enclosed a WIP patch from one of my co-workers
>>> intended to support JDBC's setQueryTimeout, along with the patch
>>> for JDBC that uses it.
>
>> I agree that it would be very nice
"Kevin Grittner" writes:
> David Fetter wrote:
>> Please find enclosed a WIP patch from one of my co-workers
>> intended to support JDBC's setQueryTimeout, along with the patch
>> for JDBC that uses it.
> I agree that it would be very nice to support this JDBC feature, but
> I'm not clear on wh
David Fetter wrote:
> Please find enclosed a WIP patch from one of my co-workers
> intended to support JDBC's setQueryTimeout, along with the patch
> for JDBC that uses it.
I agree that it would be very nice to support this JDBC feature, but
I'm not clear on why this can't be done with just JD
44 matches
Mail list logo
