From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Michael Paquier' <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: [doc fix] PG10: wroing description on connect_timeout when multiple hosts are specified |
Date: | 2017-05-17 02:49:07 |
Message-ID: | 0A3221C70F24FB45833433255569204D1F6F9873@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)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 now for the same reason Robert mentioned.
> + int ret = 0;
> + int timeout = 0;
> The declaration of "ret" should be internal in the for(;;) loop.
Done.
> + /* Attempt connection to the next host, starting the
> connect_timeout timer */
> + pqDropConnection(conn, true);
> + conn->addr_cur = conn->connhost[conn->whichhost].addrlist;
> + conn->status = CONNECTION_NEEDED;
> + finish_time = time(NULL) + timeout;
> + }
> I think that it would be safer to not set finish_time if
> conn->connect_timeout is NULL. I agree that your code works because
> pqWaitTimed() will never complain on timeout reached if finish_time is -1.
> That's for robustness sake.
Done, but I'm not sure how this contributes to the robustness. I guess you were concerned just in case pqWaitTimed() returned 0 (timeout) even when it should not.
Regards
Takayuki Tsunakawa
Attachment | Content-Type | Size |
---|---|---|
libpq-retry-connect-on-timeout_v2.patch | application/octet-stream | 3.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-05-17 02:58:21 | Re: If subscription to foreign table valid ? |
Previous Message | Tom Lane | 2017-05-17 02:39:29 | Re: COPY FROM STDIN behaviour on end-of-file |