Re: SSI predicate locking on heap -- tuple or row? - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: SSI predicate locking on heap -- tuple or row?
Date
Msg-id 4DD8177C020000250003DAD4@gw.wicourts.gov
Whole thread Raw
In response to SSI predicate locking on heap -- tuple or row?  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: SSI predicate locking on heap -- tuple or row?  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Jeff Janes
Date:
Subject: Re: eviscerating the parser
Next
From: Robert Haas
Date:
Subject: Re: eviscerating the parser