On Thursday, September 14, 2017, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 3:23 AM, Tsunakawa, Takayuki
> > wrote:
> > Sorry again, but how can we handle this? A non-PG-developer, Tels (and
> possibly someone else, IIRC) claimed that the behavior be changed during
> the beta period. Why shou
On Thu, May 18, 2017 at 8:11 PM, Michael Paquier
wrote:
> On Thu, May 18, 2017 at 11:30 PM, Robert Haas wrote:
>> On Thu, May 18, 2017 at 7:06 AM, Michael Paquier
>> wrote:
>>> FWIW, I am of the opinion to not have an implementation based on any
>>> SQLSTATE codes, as well as not doing something
On Thu, May 18, 2017 10:24 pm, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael
>> Paquier
>> On Thu, May 18, 2017 at 11:30 PM, Robert Haas
>> wrote:
>> > Because why?
>>
>> Because it is critical to let the
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> > One thing I'm worried is that people here might become more conservative
> against change once the final version is released.
>
> Any redesign after release would finish by bein
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> On Thu, May 18, 2017 at 11:30 PM, Robert Haas wrote:
> > Because why?
>
> Because it is critical to let the user know as well *why* an error happened.
> Imagine that this feature
On Fri, May 19, 2017 at 11:01 AM, Tsunakawa, Takayuki
wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut
>> The problem is that if we decide to change the behavior mid-beta, then we'll
>> only have the rest of beta to find
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut
> The problem is that if we decide to change the behavior mid-beta, then we'll
> only have the rest of beta to find out whether people will like the other
> behavior.
>
> I would ai
On 5/17/17 13:19, Tom Lane wrote:
> I agree with Robert's point that major redesign of the feature on the
> basis of one complaint isn't necessarily the way to go. Since the
> existing behavior is already out in beta1, let's wait and see if anyone
> else complains. We don't need to fix it Right T
On Thu, May 18, 2017 at 11:30 PM, Robert Haas wrote:
> On Thu, May 18, 2017 at 7:06 AM, Michael Paquier
> wrote:
>> FWIW, I am of the opinion to not have an implementation based on any
>> SQLSTATE codes, as well as not doing something similar to JDBC.
>> Keeping things simple is one reason, a sec
On Thu, May 18, 2017 at 7:06 AM, Michael Paquier
wrote:
> FWIW, I am of the opinion to not have an implementation based on any
> SQLSTATE codes, as well as not doing something similar to JDBC.
> Keeping things simple is one reason, a second is that the approach
> taken by libpq is correct at its r
On Thu, May 18, 2017 at 5:05 PM, Tsunakawa, Takayuki
wrote:
> So, how about trying connection to the next host when the class code is
> neither 28, 3D, nor 42?
>
> Honestly, I'm not happy with this approach, for a maintenance reason that
> others are worried about. Besides, when the connection
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,
> Takayuki
> Done. I'll examine whether we can use SQLSTATE.
I tried conceivable errors during connection. Those SQLSTATEs are as follows:
[transient error (after which you may want to
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> Does JDBC use something like that to make a difference between a failure
> and a move-on-to-next-one?
No, it just tries the next host. See the first while loop in
org/postgresql/jdbc/core/v3/ConnectionFactoryImpl.java.
> From maintena
On Thu, May 18, 2017 at 12:07 PM, Tsunakawa, Takayuki
wrote:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> Maybe add this to the list of open issues to reconsider mid-beta?
>
> Done. I'll examine whether we can use SQLSTATE.
Does JDBC use something like that to make a difference between a
fail
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sure, but part of the point of beta testing is to get user feedback.
Yes, and I'm also proposing this in the user's point of view, which I believe
holds true for people here. I'm worried from my support experience that strict
customers would complain
Moin,
On Wed, May 17, 2017 12:34 pm, Robert Haas wrote:
> On Wed, May 17, 2017 at 3:06 AM, Tsunakawa, Takayuki
> wrote:
>> What do you think of the following cases? Don't you want to connect to
>> other servers?
>>
>> * The DBA shuts down the database. The server takes a long time to do
>> chec
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I agree with Robert's point that major redesign of the feature on the
> basis of one complaint isn't necessarily the way to go. Since the
> existing behavior is already out in beta1, let's wait and see if anyone
> else complains. We don't need to fix
On Wed, May 17, 2017 at 12:06 AM, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: pgsql-hackers-ow...@postgresql.org
> > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> > Who is right is a judgement call, but I don't think it's self-evident
> that
> > us
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> One good argument for leaving this alone entirely is that this feature
>> was committed on November 3rd and this thread began on May 12th. If
>> there was ample time before feature freeze to question the design and
>> nobody
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> One good argument for leaving this alone entirely is that this feature
> was committed on November 3rd and this thread began on May 12th. If
> there was ample time before feature freeze to question the design and
> nobody did, then I'm not su
On Wed, May 17, 2017 at 12:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> Yeah, you have a point. I'm willing to admit that we may have defined
>> the behavior of the feature incorrectly, provided that you're willing
>> to admit that you're proposing a definition change, not just a bug
>> fix.
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I suggest that we need to conditionalize the decision based on what
>> SQLSTATE is reported. Not sure offhand if it's better to have a whitelist
>> of SQLSTATEs that allow failing over to the next server, or a blacklist of
>> SQLST
Tom, Robert,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > Yeah, you have a point. I'm willing to admit that we may have defined
> > the behavior of the feature incorrectly, provided that you're willing
> > to admit that you're proposing a definition change, not just a bug
> >
Robert Haas writes:
> Yeah, you have a point. I'm willing to admit that we may have defined
> the behavior of the feature incorrectly, provided that you're willing
> to admit that you're proposing a definition change, not just a bug
> fix.
> Anybody else want to weigh in with an opinion here?
I
On Wed, May 17, 2017 at 3:06 AM, Tsunakawa, Takayuki
wrote:
> What do you think of the following cases? Don't you want to connect to other
> servers?
>
> * The DBA shuts down the database. The server takes a long time to do
> checkpointing. During the shutdown checkpoint, libpq tries to conne
Hello Robert, Tom,
Thank you for being kind enough to explain. I think I could understand your
concern.
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Who is right is a judgement call, but I don't think it's self-evident that
>
Robert Haas writes:
> On Sun, May 14, 2017 at 9:50 PM, Tsunakawa, Takayuki
> wrote:
>> By the way, could you elaborate what problem could occur if my solution is
>> applied? (it doesn't seem easy for me to imagine...)
> Sure. Imagine that the user thinks that 'foo' and 'bar' are the
> relevan
On Sun, May 14, 2017 at 9:50 PM, Tsunakawa, Takayuki
wrote:
>> I guess not as well. That would be tricky for the user to have a different
>> behavior depending on the error returned by the server, which is why the
>> current code is doing things right IMO. Now, the feature has been designed
>> sim
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> On Fri, May 12, 2017 at 10:44 PM, Tom Lane wrote:
> > I would not really expect that reconnection would retry after
> > arbitrary failure cases. Should it retry for "wrong database name", for
> instance?
> > It's not hard to imagine that
On Sun, May 14, 2017 at 9:19 PM, Michael Paquier
wrote:
> On Fri, May 12, 2017 at 10:44 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> On Fri, May 12, 2017 at 1:28 PM, Tsunakawa, Takayuki
>>> wrote:
Likewise, when the first host has already reached max_connections, libpq
doesn't
On Fri, May 12, 2017 at 10:44 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Fri, May 12, 2017 at 1:28 PM, Tsunakawa, Takayuki
>> wrote:
>>> Likewise, when the first host has already reached max_connections, libpq
>>> doesn't attempt the connection aginst later hosts.
>
>> It seems to me t
Michael Paquier writes:
> On Fri, May 12, 2017 at 1:28 PM, Tsunakawa, Takayuki
> wrote:
>> Likewise, when the first host has already reached max_connections, libpq
>> doesn't attempt the connection aginst later hosts.
> It seems to me that the feature is behaving as wanted. Or in short
> attemp
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
> It seems to me that the feature is behaving as wanted. Or in short attempt
> to connect to the next host only if a connection cannot be established.
> If there is a failure once the exchange with the server has begun, just
> consider it as
On Fri, May 12, 2017 at 1:28 PM, Tsunakawa, Takayuki
wrote:
> Likewise, when the first host has already reached max_connections, libpq
> doesn't attempt the connection aginst later hosts.
It seems to me that the feature is behaving as wanted. Or in short
attempt to connect to the next host only
Hello,
I found a problem with libpq connection failover. When libpq cannot connect to
earlier hosts in the host list, it doesn't try to connect to other hosts. For
example, when you specify a wrong port that some non-postgres program is using,
or some non-postgres program is using PG's port u
35 matches
Mail list logo