Re: SSI predicate locking on heap -- tuple or row?
От | Kevin Grittner |
---|---|
Тема | Re: SSI predicate locking on heap -- tuple or row? |
Дата | |
Msg-id | 4DD8177C020000250003DAD4@gw.wicourts.gov обсуждение исходный текст |
Ответ на | SSI predicate locking on heap -- tuple or row? ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: SSI predicate locking on heap -- tuple or row?
|
Список | pgsql-hackers |
Robert Haas wrote: > How is an UPDATE different from a DELETE and an INSERT? That's the question Jeff asked which caused us to revisit this. There are two answers -- conceptual and implementation. Conceptually, an updated row is the same row, and a row inserted after a delete is a new row. Note that READ COMMITTED doesn't treat them the same on a write conflict. To give a practical example, police departments in Wisconsin typically reassign a badge number to a new officer after an existing officer leaves. Updating an officer record keyed by badge number (say, with a new address or a name change) would be qualitatively different from deleting an old officer record and inserting a new one for a different person now getting the badge number.(OK, so this is somewhat artificial, because theytrack who had the number in what temporal ranges, but you get the idea.) In the implementation the only difference between an UPDATE in a table and a DELETE and INSERT in the same table in the same transaction (besides concurrency handling) is the ctid linkage, at least as far as I can see. So I think that you can't just treat the two things the same in SSI just because the PostgreSQL implementation details make them similar; but I think that you can treat the two things the same for the reasons I worked out at the start of the thread. -Kevin
В списке pgsql-hackers по дате отправления: