From: | David Johnston <polobo(at)yahoo(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Update with subselect sometimes returns wrong result |
Date: | 2013-12-01 03:00:01 |
Message-ID: | 1385866801641-5781041.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-12-01 06:41:02 | Re: Update with subselect sometimes returns wrong result |
Previous Message | Andres Freund | 2013-11-30 21:40:18 | Re: Update with subselect sometimes returns wrong result |