On Thu, May 4, 2017 at 10:40 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, May 4, 2017 at 1:04 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> On Thu, May 4, 2017 at 10:18 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> On Thu, May 4, 2017 at 12:18 PM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers