diff options
| author | Etsuro Fujita <efujita@postgresql.org> | 2024-04-04 17:25:00 +0900 |
|---|---|---|
| committer | Etsuro Fujita <efujita@postgresql.org> | 2024-04-04 17:25:00 +0900 |
| commit | f6f61a4bd9cc8d771c3b33feeee5cfc039c5e05d (patch) | |
| tree | 843114e2c9adba2d8fd1d588f808f0285d2f07a3 /contrib/postgres_fdw/postgres_fdw.c | |
| parent | bafad43c37bf531f392e65ba726c253040b608f2 (diff) | |
| download | postgresql-f6f61a4bd9cc8d771c3b33feeee5cfc039c5e05d.tar.gz postgresql-f6f61a4bd9cc8d771c3b33feeee5cfc039c5e05d.zip | |
Fix bogus coding in ExecAppendAsyncEventWait().
No configured-by-FDW events would result in "return" directly out of a
PG_TRY block, making the exception stack dangling. Repair.
Oversight in commit 501cfd07d; back-patch to v14, like that commit, but
as we do not have this issue in HEAD (cf. commit 50c67c201), no need to
apply this patch to it.
In passing, improve a comment about the handling of in-process requests
in a postgres_fdw.c function called from this function.
Alexander Pyhalov, with comment adjustment/improvement by me.
Discussion: https://postgr.es/m/425fa29a429b21b0332737c42a4fdc70%40postgrespro.ru
Diffstat (limited to 'contrib/postgres_fdw/postgres_fdw.c')
| -rw-r--r-- | contrib/postgres_fdw/postgres_fdw.c | 18 |
1 files changed, 10 insertions, 8 deletions
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c index c5cada55fb7..23a57104e85 100644 --- a/contrib/postgres_fdw/postgres_fdw.c +++ b/contrib/postgres_fdw/postgres_fdw.c @@ -7174,14 +7174,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; |