>>> "Robert Haas" <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Dec 29, 2008 at 9:28 PM, Gregory Stark
<stark(at)enterprisedb(dot)com> wrote:
>> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>>> (3) A finer-grained approach would be to make no-effect updates
to
>>> rows to lock them if they are to be read for purposes of updating
>>> something else in the transaction. This could have a high cost in
>>> disk access and table bloat. It has the advantage of providing a
>>> simple technique which, if applied consistently, doesn't require
>>> knowledge of software beyond what is under development.
>>
>> "no-effect updates" would be just the same as SELECT FOR UPDATE
>
> ...except that SELECT FOR UPDATE won't create table bloat, or as
much
> I/O... I think?
The effects are different, I think, in that there isn't a
serialization failure in some conflict cases where you would get one
with actual updates. I found a paper on how to use updates to provide
serializable transactions in a snapshot database, and I'd have to
review closely to see how that difference affected the technique. I
had been thinking that the WAL generation and bloat issues made the
technique pretty iffy, but if SELECT FOR UPDATE suffices in place of
most of the proposed updates, it just might be feasible.
-Kevin