Tom Lane 46e3a16b05 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.		2009-10-28 14:55:47 +00:00
..
sgml	When FOR UPDATE/SHARE is used with LIMIT, put the LockRows plan node	2009-10-28 14:55:47 +00:00
Makefile	Ship documentation without intermediate tarballs	2009-08-09 22:47:59 +00:00