From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Force NO SCROLL for plpgsql's implicit cursors. |
Date: | 2021-06-08 22:40:23 |
Message-ID: | E1lqkOV-0006It-NW@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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
Branch
------
REL_13_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/c5b28184132d30ce7f77b24b0e7f302a8f37f407
Modified Files
--------------
src/pl/plpgsql/src/pl_exec.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-06-09 03:33:17 | Re: logical decoding bug: segfault in ReorderBufferToastReplace() |
Previous Message | Tom Lane | 2021-06-08 21:50:54 | pgsql: Avoid misbehavior when persisting a non-stable cursor. |