Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitc5b2818

Browse files
committed
Force NO SCROLL for plpgsql's implicit cursors.
Further thought about bug #17050 suggests that it's a good ideato use CURSOR_OPT_NO_SCROLL for the implicit cursor opened bya plpgsql FOR-over-query loop. This ensures that, if somebodycommits inside the loop, PersistHoldablePortal won't try torewind and re-read the cursor. While we'd have selected NO_SCROLLanyway if FOR UPDATE/SHARE appears in the query, there are otherhazards with volatile functions; and in any case, it's silly toexpend effort storing rows that we know for certain won't be needed.(While here, improve the comment in exec_run_select, which was a bitconfused about the rationale for when we can use parallel mode.Cursor operations aren't a hazard for nameless portals.)This wasn't an issue until v11, which introduced the possibilityof persisting such cursors. Hence, back-patch to v11.Per bug #17050 from Алексей Булгаков.Discussion:https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org
1 parentc1fd756 commitc5b2818

File tree

1 file changed

+14
-7
lines changed

1 file changed

+14
-7
lines changed

‎src/pl/plpgsql/src/pl_exec.c

Lines changed: 14 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -4558,7 +4558,7 @@ exec_stmt_dynfors(PLpgSQL_execstate *estate, PLpgSQL_stmt_dynfors *stmt)
45584558
intrc;
45594559

45604560
portal=exec_dynquery_with_params(estate,stmt->query,stmt->params,
4561-
NULL,0);
4561+
NULL,CURSOR_OPT_NO_SCROLL);
45624562

45634563
/*
45644564
* Execute the loop
@@ -5903,14 +5903,21 @@ exec_run_select(PLpgSQL_execstate *estate,
59035903
* On the first call for this expression generate the plan.
59045904
*
59055905
* If we don't need to return a portal, then we're just going to execute
5906-
* the query once, which means it's OK to use a parallel plan, even if the
5907-
* number of rows being fetched is limited. If we do need to return a
5908-
* portal, the caller might do cursor operations, which parallel query
5909-
* can't support.
5906+
* the query immediately, which means it's OK to use a parallel plan, even
5907+
* if the number of rows being fetched is limited. If we do need to
5908+
* return a portal (i.e., this is for a FOR loop), the user's code might
5909+
* invoke additional operations inside the FOR loop, making parallel query
5910+
* unsafe. In any case, we don't expect any cursor operations to be done,
5911+
* so specify NO_SCROLL for efficiency and semantic safety.
59105912
*/
59115913
if (expr->plan==NULL)
5912-
exec_prepare_plan(estate,expr,
5913-
portalP==NULL ?CURSOR_OPT_PARALLEL_OK :0, true);
5914+
{
5915+
intcursorOptions=CURSOR_OPT_NO_SCROLL;
5916+
5917+
if (portalP==NULL)
5918+
cursorOptions |=CURSOR_OPT_PARALLEL_OK;
5919+
exec_prepare_plan(estate,expr,cursorOptions, true);
5920+
}
59145921

59155922
/*
59165923
* Set up ParamListInfo to pass to executor

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp