From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, robertmhaas(at)gmail(dot)com, 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-23 14:20:21 |
Message-ID: | 12537.1306160421@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aidan Van Dyk <aidan(at)highrise(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-23 14:34:37 | Re: 9.1 support for hashing arrays |
Previous Message | Tom Lane | 2011-05-23 13:58:24 | Re: Foreign memory context read |