]> git.ipfire.org Git - thirdparty/postgresql.git/commitdiff
postgres_fdw: Improve comment about handling of asynchronous requests.
authorEtsuro Fujita <efujita@postgresql.org>
Thu, 11 Apr 2024 10:25:00 +0000 (19:25 +0900)
committerEtsuro Fujita <efujita@postgresql.org>
Thu, 11 Apr 2024 10:25:00 +0000 (19:25 +0900)
We updated this comment in back branches (see commit f6f61a4bd et al);
let's do so in HEAD as well for consistency.

Discussion: https://postgr.es/m/CAPmGK142V1kqDfjo2H%2Bb54JTn2woVBrisFq%2B%3D9jwXwxr0VvbgA%40mail.gmail.com

contrib/postgres_fdw/postgres_fdw.c

index 142dcfc9957731abdb7763769f8ca54c6b3b1db9..4053cd641c550385fbd517785af98777cf6ecc7f 100644 (file)
@@ -7270,14 +7270,16 @@ postgresForeignAsyncConfigureWait(AsyncRequest *areq)
        {
                /*
                 * This is the case when the in-process request was made by another
-                * Append.  Note that it might be useless to process the request,
-                * because the query might not need tuples from that Append anymore.
-                * If there are any child subplans of the same parent that are ready
-                * for new requests, skip the given request.  Likewise, if there are
-                * any configured events other than the postmaster death event, skip
-                * it.  Otherwise, process the in-process request, then begin a fetch
-                * to configure the event below, because we might otherwise end up
-                * with no configured events other than the postmaster death event.
+                * Append.  Note that it might be useless to process the request made
+                * by that Append, because the query might not need tuples from that
+                * Append anymore; so we avoid processing it to begin a fetch for the
+                * given request if possible.  If there are any child subplans of the
+                * same parent that are ready for new requests, skip the given
+                * request.  Likewise, if there are any configured events other than
+                * the postmaster death event, skip it.  Otherwise, process the
+                * in-process request, then begin a fetch to configure the event
+                * below, because we might otherwise end up with no configured events
+                * other than the postmaster death event.
                 */
                if (!bms_is_empty(requestor->as_needrequest))
                        return;