Wiki / Plan Nodes / Control
LockRows
LockRows
Locks rows selected by its child for row-locking clauses.
Reading PostgreSQL 18.6.
Description
Locks rows selected by its child for row-locking clauses.
- Core node tag
- T_LockRows
- Structured EXPLAIN Node Type
- LockRows
- Inputs
- One child plan with row identity information
- Output
- Locked qualifying tuples
- Executor initializer
- ExecInitLockRows
- Memory mechanism
- unclassified
EXPLAIN names and attributes
Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.
Text names recorded by this source: LockRows.
Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node.
Memory and temporary storage
This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.
Parallel execution and instrumentation
The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.
Callbacks in this build: none extracted from this node implementation.
Executor implementation notes
nodeLockRows.c Routines to handle FOR UPDATE/FOR SHARE row locking
We don't need EvalPlanQual unless we get updated tuple version(s)
Attempt to lock the source tuple(s). (Note we only have locking rowmarks in lr_arowMarks.)
if FDW says tuple was updated before getting locked, we need to perform EPQ testing to see if quals are still satisfied
The target tuple was already updated or deleted by the current command, or by a later command in the current transaction. We *must* ignore the tuple in the former case, so as to avoid the "Halloween problem" of repeated update attempts. In the latter case it might be sensible to fetch the updated tuple instead, but doing so would require changing heap_update and heap_delete to not complain about updating "invisible" tuples, which seems pretty scary (table_tuple_lock will not complain, but few callers expect TM_Invisible, and we're not one of them). So for now, treat the tuple as deleted and do not process.
EXPLAIN identity in core source
case T_LockRows:
pname = sname = "LockRows";
break;EXPLAIN labels in this source build
| Text-format label | Structured node identity |
|---|---|
| LockRows | LockRows |
Related entries
Documentation and source
- src/backend/commands/explain.c:1598
- src/backend/executor/execProcnode.c:375
- src/backend/executor/nodeLockRows.c
- src/include/nodes/plannodes.h
Source build
- Version
- 18.6
- Build
- PostgreSQL 18.6 source archive
- Source fingerprint
555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f
Compare versions
PostgreSQL 17 → 18: unchanged.
Compares recorded interfaces and attributes. Source fingerprints and build metadata are excluded; an absent sample is not proof of the introduction or removal release.
Related entries
LimitLimitProjectSetProjectSetResultResult
Export JSON · Back to Plan Nodes · Recorded in PostgreSQL 10 through 20; the first sample is not necessarily its introduction.