From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Committed. I also added a slight tweak to the wording of the documentation.
Thank you, the doc looks clearer.
Regards
Takayuki Tsunakawa
--
Sent via pgsql-hackers mailing list (pg
On Tue, May 16, 2017 at 11:58 PM, Michael Paquier
wrote:
> Thanks for the updated patch. This looks good to me.
Committed. I also added a slight tweak to the wording of the documentation.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
On Wed, May 17, 2017 at 11:49 AM, Tsunakawa, Takayuki
wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
>> pqWait is internal to libpq, so we are free to set up what we want here.
>> Still I think that we should be consist
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> pqWait is internal to libpq, so we are free to set up what we want here.
> Still I think that we should be consistent with what pqSocketCheck returns:
Please let this what it is no
On Wed, May 17, 2017 at 12:47 AM, Robert Haas wrote:
> On Mon, May 15, 2017 at 9:59 PM, Michael Paquier
> wrote:
>> + *
>> + * Returns -1 on failure, 0 if the socket is readable/writable, 1 if
>> it timed out.
>> */
>> pqWait is internal to libpq, so we are free to set up what we want
>> here.
On Mon, May 15, 2017 at 9:59 PM, Michael Paquier
wrote:
> + *
> + * Returns -1 on failure, 0 if the socket is readable/writable, 1 if
> it timed out.
> */
> pqWait is internal to libpq, so we are free to set up what we want
> here. Still I think that we should be consistent with what
> pqSocketC
Hello Robert, Tom, Michael,
Thanks a lot for checking my patch. Sorry, let me check Michael's review
comments and reply tomorrow.
Regards
Takayuki Tsunakawa
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On Tue, May 16, 2017 at 3:13 AM, Tom Lane wrote:
> FWIW, I think the position most of us were taking is that this feature
> is meant to retry transport-level connection failures, not cases where
> we successfully make a connection to a server and then it rejects our
> login attempt. I would class
Robert Haas writes:
> Takayuki Tsunakawa raised a very similar issue in another thread
> related to another open item, namely
> https://www.postgresql.org/message-id/flat/0A3221C70F24FB45833433255569204D1F6F5659%40G01JPEXMBYT05
> in which he argued that libpq ought to try then next host after a
>
On Sun, May 14, 2017 at 11:45 PM, Noah Misch wrote:
>> I'll add this item in the PostgreSQL 10 Open Items.
>
> [Action required within three days. This is a generic notification.]
I think there is a good argument that the existing behavior is as per
the documentation, but I think we may want to
On Fri, May 12, 2017 at 08:54:13AM +, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-ow...@postgresql.org
> > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,
> > Takayuki
> > I found a wrong sentence here in the doc. I'm sorry, this is what I asked
> > you to add...
> >
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,> Takayuki
> Instead, I think we should fix the program to match the documented behavior.
> Otherwise, if the first database machine is down, libpq might wait for about
> 2 hours (depending
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,
> Takayuki
> I found a wrong sentence here in the doc. I'm sorry, this is what I asked
> you to add...
>
> https://www.postgresql.org/docs/devel/static/libpq-connect.html#libpq-
> paramk
13 matches
Mail list logo