forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit217dc52
committed
Fix oversight in EvalPlanQualFetch: after failing to lock a tuple because
someone else has just updated it, we have to set priorXmax to that tuple'sxmax (ie, the XID of the other xact that updated it) before looping back toexamine the next tuple. Obviously, the next tuple in the update chain shouldhave that XID as its xmin, not the same xmin as the preceding tuple that wehad been trying to lock. The mismatch would cause the EvalPlanQual logic todecide that the tuple chain ended in a deletion, when actually there was alive tuple that should have been found.I inserted this error when recently adding logic to EvalPlanQual to make itlock tuples before returning them (as opposed to the old method in which thelock would occur much later, causing a great deal of work to be wasted if weonly then discover someone else updated it). Sigh. Per today's report fromTakahiro Itagaki of inconsistent results during pgbench runs.1 parent83a5a33 commit217dc52
1 file changed
+3
-1
lines changedLines changed: 3 additions & 1 deletion
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
26 | 26 |
| |
27 | 27 |
| |
28 | 28 |
| |
29 |
| - | |
| 29 | + | |
30 | 30 |
| |
31 | 31 |
| |
32 | 32 |
| |
| |||
1546 | 1546 |
| |
1547 | 1547 |
| |
1548 | 1548 |
| |
| 1549 | + | |
| 1550 | + | |
1549 | 1551 |
| |
1550 | 1552 |
| |
1551 | 1553 |
| |
|
0 commit comments
Comments
(0)