Re: Update with subselect sometimes returns wrong result

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.