mirror of
https://github.com/postgres/postgres.git
synced 2025-07-15 19:21:59 +03:00
When FOR UPDATE/SHARE is used with LIMIT, put the LockRows plan node
underneath the Limit node, not atop it. This fixes the old problem that such a query might unexpectedly return fewer rows than the LIMIT says, due to LockRows discarding updated rows. There is a related problem that LockRows might destroy the sort ordering produced by earlier steps; but fixing that by pushing LockRows below Sort would create serious performance problems that are unjustified in many real-world applications, as well as potential deadlock problems from locking many more rows than expected. Instead, keep the present semantics of applying FOR UPDATE after ORDER BY within a single query level; but allow the user to specify the other way by writing FOR UPDATE in a sub-select. To make that work, track whether FOR UPDATE appeared explicitly in sub-selects or got pushed down from the parent, and don't flatten a sub-select that contained an explicit FOR UPDATE.
This commit is contained in:
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/nodes/outfuncs.c,v 1.370 2009/10/26 02:26:31 tgl Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/nodes/outfuncs.c,v 1.371 2009/10/28 14:55:38 tgl Exp $
|
||||
*
|
||||
* NOTES
|
||||
* Every node type that can appear in stored rules' parsetrees *must*
|
||||
@ -1987,6 +1987,7 @@ _outQuery(StringInfo str, Query *node)
|
||||
WRITE_BOOL_FIELD(hasSubLinks);
|
||||
WRITE_BOOL_FIELD(hasDistinctOn);
|
||||
WRITE_BOOL_FIELD(hasRecursive);
|
||||
WRITE_BOOL_FIELD(hasForUpdate);
|
||||
WRITE_NODE_FIELD(cteList);
|
||||
WRITE_NODE_FIELD(rtable);
|
||||
WRITE_NODE_FIELD(jointree);
|
||||
@ -2036,6 +2037,7 @@ _outRowMarkClause(StringInfo str, RowMarkClause *node)
|
||||
WRITE_UINT_FIELD(rti);
|
||||
WRITE_BOOL_FIELD(forUpdate);
|
||||
WRITE_BOOL_FIELD(noWait);
|
||||
WRITE_BOOL_FIELD(pushedDown);
|
||||
}
|
||||
|
||||
static void
|
||||
|
Reference in New Issue
Block a user