diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-06-08 18:40:06 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-06-08 18:40:06 -0400 |
commit | 18232330062026d3575ec5f387b70f63a856e0ea (patch) | |
tree | fb6962babc00836691fa1e76e5de0db694189e5b /src/backend/access/transam/xlog.c | |
parent | c3b5082685dd6f9f6b76c227e04ae8dca720acc5 (diff) |
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/access/transam/xlog.c')
0 files changed, 0 insertions, 0 deletions