Andres Freund-3 wrote
> deleted row at: (0,1)
> deleted row at: (0,5)
> new row at: (0,1)
> new row at: (0,5)
> updated row from (0,1) to (0,3) iter 401
> deleted row at: (0,2)
> deleted row at: (0,3)
Am I reading this right?
Rows == ctid(,#)
Rows 1 & 5 exist; are deleted
Add two new rows, store them at 1 & 5 replacing the just deleted rows
--? does auto-vacuum work that fast that these physical locations are
immediately available...
Update row 1, store new value in 3 marking 1 as deleted (not shown here)
Rows 2? & 3 exist and are now deleted
?Where did Row 2 come from...was expecting row 5...?
> new row at: (0,2)
> new row at: (0,3)
> updated row from (0,1) to (0,3) iter 405
> deleted row at: (0,2)
> deleted row at: (0,3)
Likewise: how did Row 1 come into being (so that it could be updated) when
only 2 and 3 were added on the prior iteration?
Then, at the point of the assertion failure, rows 4 & 5 are updated but rows
2 & 3 were the rows that were added...so neither of the just-inserted rows
were returned...
Sorry I cannot actually debug code but figured my observations might be
helpful none-the-less.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Update-with-subselect-sometimes-returns-wrong-result-tp5780925p5781041.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
