"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
However this has the same problem that we previously discussed where someone
can still add new records which would have changed the results of the query.
Ask me about EnterpriseDB's Slony Replication support!
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2008-12-30 03:16:27|
|Subject: Re: Documenting serializable vs snapshot isolation levels|
|Previous:||From: Andrew Chernow||Date: 2008-12-30 01:46:04|
|Subject: Re: new libpq SSL connection option|