Re: SSI predicate locking on heap -- tuple or row?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SSI predicate locking on heap -- tuple or row?
Дата
Msg-id 12537.1306160421@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SSI predicate locking on heap -- tuple or row?  (Aidan Van Dyk <aidan@highrise.ca>)
Ответы Re: SSI predicate locking on heap -- tuple or row?
Список pgsql-hackers
Aidan Van Dyk <aidan@highrise.ca> writes:
> So, if SSI conflicts something on the UPDATE case, it would necessrily
> have to conflict the DELETE+INSERT case as well, and vice-versa.

This argument is fundamentally bogus, because an UPDATE is not the same
thing as DELETE followed by INSERT.  In the former case the new tuple
will have a ctid link from the old one; in the latter case not.  And
that will affect the behavior of subsequent operations.  Another
user-visible difference is that if the table has OIDs, the latter case
will (usually) give the new tuple a different OID.  Or if you don't like
OIDs, think about a serial column.  Or an ON INSERT trigger with
side-effects.

It may be that the result Kevin seeks to prove is in fact true, but an
argument that requires the assumption that UPDATE is indistinguishable
from DELETE+INSERT isn't going to persuade me, because I don't have any
trouble whatsoever in distinguishing them.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Aidan Van Dyk
Дата:
Сообщение: Re: SSI predicate locking on heap -- tuple or row?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: 9.1 support for hashing arrays