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 по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: eviscerating the parser
Следующее
От: Robert Haas
Дата:
Сообщение: Re: eviscerating the parser