forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commitbb4aed4
committed
Shut down EvalPlanQual machinery when LockRows node reaches the end.
Previously, we left the EPQ sub-executor alone until ExecEndLockRows.This caused any buffer pins or other resources that it might hold toremain held until ExecutorEnd, which in some code paths means thatthey are held till the Portal is closed. That can cause user-visibleproblems, such as blocking VACUUM; and it's unlike the behavior ofordinary table-scanning nodes, which will have released all bufferpins by the time they return an EOF indication.We can make LockRows work more like other plan nodes by callingEvalPlanQualEnd just before returning NULL. We still need to call itin ExecEndLockRows in case the node was not run to completion, but inthe normal case the second call does nothing and costs little.Per report from Yura Sokolov. In principle this is a longstandingbug, but in view of the lack of other complaints and the low severityof the consequences, I chose not to back-patch.Discussion:https://postgr.es/m/4aa370cb91ecf2f9885d98b80ad1109c@postgrespro.ru1 parent9bb5eec commitbb4aed4
1 file changed
+5
-0
lines changedLines changed: 5 additions & 0 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
59 | 59 |
| |
60 | 60 |
| |
61 | 61 |
| |
| 62 | + | |
| 63 | + | |
| 64 | + | |
62 | 65 |
| |
| 66 | + | |
63 | 67 |
| |
64 | 68 |
| |
65 | 69 |
| |
| |||
381 | 385 |
| |
382 | 386 |
| |
383 | 387 |
| |
| 388 | + | |
384 | 389 |
| |
385 | 390 |
| |
386 | 391 |
| |
|
0 commit comments
Comments
(0)