On Thu, May 4, 2017 at 10:40 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, May 4, 2017 at 1:04 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Thu, May 4, 2017 at 10:18 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Thu, May 4, 2017 at 12:18 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>>> As soon as the first command fails due to timeout, we will set
>>>> 'abort_cleanup_failure' which will make a toplevel transaction to
>>>> abort and also won't allow other statements to execute. The patch is
>>>> trying to enforce a 30-second timeout after statement execution, so it
>>>> has to anyway wait till the command execution completes (irrespective
>>>> of whether the command succeeds or fail).
>>>
>>> I don't understand what you mean by this. If the command doesn't
>>> finish within 30 seconds, we *don't* wait for it to finish.
>>>
>>
>> + /*
>> + * Submit a query. Since we don't use non-blocking mode, this also can
>> + * block. But its risk is relatively small, so we ignore that for now.
>> + */
>> + if (!PQsendQuery(conn, query))
>> + {
>> + pgfdw_report_error(WARNING, NULL, conn, false, query);
>> + return false;
>> + }
>> +
>> + /* Get the result of the query. */
>> + if (pgfdw_get_cleanup_result(conn, endtime, &result))
>> + return false;
>>
>> The 30 seconds logic is in function pgfdw_get_cleanup_result, can't
>> the command hang in PQsendQuery?
>
> Sure. I thought about trying to fix that too, by using
> PQsetnonblocking(), but I thought the patch was doing enough already.
>
Okay, it seems better to deal it in a separate patch.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
