Обсуждение: For update clause
Hi, I am one of the french translators of the documentation. I am translating the reference page of SELECT, but I fail to understand this sentence about the FOR UPDATE clause ( http://www.postgresql.org/docs/9.0/static/sql- select.html#SQL-FOR-UPDATE-SHARE ) --------------- In addition, rows that satisfied the query conditions as of the query snapshot will be locked, although they will not be returned if they have since been updated to not satisfy the query conditions. ------------------ Could anyone please explain it to me, so that I can translate it properly? A word for word translation has really no meaning. Florence
Florence Cousin wrote: > Hi, > > I am one of the french translators of the documentation. I am translating the > reference page of SELECT, but I fail to understand this sentence about the FOR > UPDATE clause ( http://www.postgresql.org/docs/9.0/static/sql- > select.html#SQL-FOR-UPDATE-SHARE ) > > --------------- > In addition, rows that satisfied the query conditions as of the query snapshot > will be locked, although they will not be returned if they have since been > updated to not satisfy the query conditions. > ------------------ > > Could anyone please explain it to me, so that I can translate it properly? A > word for word translation has really no meaning. Wow, that is a confusing double-negative sentence. I have updated the text to be: In addition, rows that satisfied the query conditions as of the query snapshot will be locked, although they will not be returned if they were updated after the snapshot and no longer satisfy the query conditions. What it is saying is that SELECT FOR UPDATE will lock all rows that match the SELECT query using the current snapshot, but the returned rows might be different because the rows were changed after the snapshot was taken, and a SELECT FOR UPDATE will return the rows as UPDATE will see them, which might not match the SELECT snapshot. Yeah, it is confusing. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
Le mardi 15 juin 2010 22:04:06, Bruce Momjian a écrit : > > Wow, that is a confusing double-negative sentence. I have updated the > text to be: > > In addition, rows that satisfied the query conditions as of the > query snapshot will be locked, although they will not be returned > if they were updated after the snapshot and no longer satisfy the > query conditions. > > What it is saying is that SELECT FOR UPDATE will lock all rows that > match the SELECT query using the current snapshot, but the returned rows > might be different because the rows were changed after the snapshot was > taken, and a SELECT FOR UPDATE will return the rows as UPDATE will see > them, which might not match the SELECT snapshot. Yeah, it is confusing. Thank you for the patch and the explanation. It is clear for me now (the rows returned are those that would be returned by an UPDATE, that is pretty logical). But I think most of the users will still not understand this, because they do not know what a snapshot is, and do not really know how locking works. And I managed to understand thank to the explanation, but I think I could not understand with the new version of the explanation alone (the fact that rows returned are the rows as UPDATE will see them) Maybe it would be clearer with a longer explanation, or a link to an explanation?
Florence Cousin wrote: > Le mardi 15 juin 2010 22:04:06, Bruce Momjian a ?crit : > > > > Wow, that is a confusing double-negative sentence. I have updated the > > text to be: > > > > In addition, rows that satisfied the query conditions as of the > > query snapshot will be locked, although they will not be returned > > if they were updated after the snapshot and no longer satisfy the > > query conditions. > > > > What it is saying is that SELECT FOR UPDATE will lock all rows that > > match the SELECT query using the current snapshot, but the returned rows > > might be different because the rows were changed after the snapshot was > > taken, and a SELECT FOR UPDATE will return the rows as UPDATE will see > > them, which might not match the SELECT snapshot. Yeah, it is confusing. > > Thank you for the patch and the explanation. It is clear for me now (the rows > returned are those that would be returned by an UPDATE, that is pretty > logical). > > But I think most of the users will still not understand this, because they do > not know what a snapshot is, and do not really know how locking works. > > And I managed to understand thank to the explanation, but I think I could not > understand with the new version of the explanation alone (the fact that rows > returned are the rows as UPDATE will see them) > > Maybe it would be clearer with a longer explanation, or a link to an > explanation? Well, the entire area is very complicated, but do we want to add even more text there? I am not sure. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +