aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/functions.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-06-08 18:40:06 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2021-06-08 18:40:06 -0400
commitbe90098907475f3cfff7dc6d590641b9c2dae081 (patch)
tree37fe5e30e1c4d36dc0695b45f8955962064d4e98 /src/backend/executor/functions.c
parentba2c6d6cec000f0aeaeda4d56a23a335f6164860 (diff)
downloadpostgresql-be90098907475f3cfff7dc6d590641b9c2dae081.tar.gz
postgresql-be90098907475f3cfff7dc6d590641b9c2dae081.zip
Force NO SCROLL for plpgsql's implicit cursors.
Further thought about bug #17050 suggests that it's a good idea to use CURSOR_OPT_NO_SCROLL for the implicit cursor opened by a plpgsql FOR-over-query loop. This ensures that, if somebody commits inside the loop, PersistHoldablePortal won't try to rewind and re-read the cursor. While we'd have selected NO_SCROLL anyway if FOR UPDATE/SHARE appears in the query, there are other hazards with volatile functions; and in any case, it's silly to expend effort storing rows that we know for certain won't be needed. (While here, improve the comment in exec_run_select, which was a bit confused 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 possibility of persisting such cursors. Hence, back-patch to v11. Per bug #17050 from Алексей Булгаков. Discussion: https://postgr.es/m/17050-f77aa827dc85247c@postgresql.org
Diffstat (limited to 'src/backend/executor/functions.c')
0 files changed, 0 insertions, 0 deletions