Re: determine snapshot after obtaining locks for first statement
От | Tom Lane |
---|---|
Тема | Re: determine snapshot after obtaining locks for first statement |
Дата | |
Msg-id | 4120.1261071598@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: determine snapshot after obtaining locks for first statement ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: determine snapshot after obtaining locks for first statement
Re: determine snapshot after obtaining locks for first statement |
Список | pgsql-hackers |
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > Tom Lane <tgl@sss.pgh.pa.us> wrote: >> http://developer.postgresql.org/pgdocs/postgres/transaction-iso.html#XACT-READ-COMMITTED > I don't know how many times I've read that page (many), yet I never > properly comprehended the impact of that part. I think the last bit > I quoted above is somewhat misleading, in that it implies that the > issue is limited to complex search conditions. In the failing case > I showed in this thread, the search conditions involved are > comparisons for equality of an integer literal to the one-column > integer primary key. It seems like any join or subquery which > references a table is vulnerable, yes? Well, it would all depend on what you're trying to do. Typical single-row UPDATE commands aren't really affected by this problem, and in fact the behavior is pretty much exactly what they want as long as the WHERE conditions don't involve columns that are being changed. Maybe we should replace the bit about "complex search conditions" with something about referencing multiple rows to perform one update. I'm not very sure what a clearer explanation would look like though. regards, tom lane
В списке pgsql-hackers по дате отправления: