Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return

Proposed fix:


Reorder Limit/LockRows nodes to prevent locking extra tuples in FETCH FIRST WITH TIES

Reference bug report: 16676

1 file changed, 12 insertions(+), 12 deletions(-)
src/backend/optimizer/plan/planner.c | 24 ++++++++++++------------

modified   src/backend/optimizer/plan/planner.c
@@ -2293,6 +2293,18 @@ grouping_planner(PlannerInfo *root, bool inheritance_update,
     {
         Path       *path = (Path *) lfirst(lc);

+        /*
+         * If there is a LIMIT/OFFSET clause, add the LIMIT node.
+         */
+        if (limit_needed(parse))
+        {
+            path = (Path *) create_limit_path(root, final_rel, path,
+                                              parse->limitOffset,
+                                              parse->limitCount,
+                                              parse->limitOption,
+                                              offset_est, count_est);
+        }
+
         /*
          * If there is a FOR [KEY] UPDATE/SHARE clause, add the LockRows node.
          * (Note: we intentionally test parse->rowMarks not root->rowMarks
@@ -2307,18 +2319,6 @@ grouping_planner(PlannerInfo *root, bool inheritance_update,
                                                  assign_special_exec_param(root));
         }

-        /*
-         * If there is a LIMIT/OFFSET clause, add the LIMIT node.
-         */
-        if (limit_needed(parse))
-        {
-            path = (Path *) create_limit_path(root, final_rel, path,
-                                              parse->limitOffset,
-                                              parse->limitCount,
-                                              parse->limitOption,
-                                              offset_est, count_est);
-        }
-
         /*
          * If this is an INSERT/UPDATE/DELETE, and we're not being called from
          * inheritance_planner, add the ModifyTable node.