"Daniel Caune" <daniel.caune@ubisoft.com> writes: > I did the following test, removing all the where-clause from the SELECT statement. Every statement completes immediately, i.e. it doesn't block. I think you left out some critical information, like who else was doing what to the table. What it looks like to me is that the third and fourth rows in this view were live according to your transaction snapshot, but were committed dead as of current time, and so FOR UPDATE wouldn't return them. > agoratokens=> select id from "Tokens" where id IN (47, 104, 44, 42) limit 3 for update; > This time, the statement returns the row where id equals to 44. No, it returns *some* row where id equals 44. Not necessarily the same one seen in the seqscan. (I imagine this query is using an index, and so would visit rows in a different physical order.) Printing the ctid of the rows would confirm or disprove that theory. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

"Daniel Caune" <daniel.caune@ubisoft.com> writes: > It seems that, in certain condition, row (199,84) is shadowing row > (3702,85); This would be the expected behavior if row (199,84) were an updated version of row (3702,85), but you couldn't see it yet in your current transaction snapshot. A plain SELECT would show the older version (the current one according to the snapshot) while SELECT FOR UPDATE would show the newest committed version. I think you must have somehow got a corrupt-data situation with respect to the commit status of these rows, but it's not real clear how. Would you show us the xmin and xmax of the rows, and also the current transaction counter? (pg_controldata will give you a close-enough idea of the latter.) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings