>>> "Robert Haas" <robertmh...@gmail.com> wrote: > On Mon, Dec 29, 2008 at 9:28 PM, Gregory Stark <st...@enterprisedb.com> wrote: >> "Kevin Grittner" <kevin.gritt...@wicourts.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
