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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <robertmhaas(at)gmail(dot)com>
Cc: <drkp(at)csail(dot)mit(dot)edu>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI predicate locking on heap -- tuple or row?
Date: 2011-05-22 00:50:20
Message-ID: 4DD8177C020000250003DAD4@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 they track 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-05-22 01:19:54 Re: eviscerating the parser
Previous Message Jeff Janes 2011-05-22 00:41:09 Re: eviscerating the parser