I wrote:
On further review it seems that a better way to do this is to make
things happen inside the EPQ machinery. We need to freeze the rows
returned by *all* scan nodes, not only the ones referencing real tables
--- for example, a join against a VALUES scan node would still be a
problem
I wrote:
[ EvalPlanQual does not work well ]
I'm planning to go back to work on this now that we're out of
CommitFest.
We could improve that by feeding successfully locked rows into the EPQ
machinery as well as ones that were found to be outdated. But that
would still leave us with two
Tom Lane t...@sss.pgh.pa.us wrote:
5. Now commit in the second session. First session resumes and
prints
f1 | f2 | f3 | f4
+++-
1 | 1 | 1 | 111
1 | 1 | 1 | 112
2 | 42 | 2 | 113
2 | 42 | 2 | 114
2 | 42 | 2 | 113
2 | 42 | 2 | 114
(6 rows)
Of
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Is this related to issue 4593?
No, not directly. Now that locking is done in a separate plan node,
we could think about addressing #4593 by switching the order of the
LockRows and Sort plan nodes, but that has nothing to do with how
well
On Mon, 2009-10-12 at 11:42 -0400, Tom Lane wrote:
The problem is that execMain.c is set up to pull as many rows as it can
from execution of an EvalPlanQual query. Then, once that's exhausted,
it steps to the next result from the original query. So if a row that
requires locking joins to
Simon Riggs si...@2ndquadrant.com writes:
On Mon, 2009-10-12 at 11:42 -0400, Tom Lane wrote:
The problem is that execMain.c is set up to pull as many rows as it can
from execution of an EvalPlanQual query. Then, once that's exhausted,
it steps to the next result from the original query. So
