>>> "Robert Haas" <robertmh...@gmail.com> wrote: >> 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. > > In fact, I think SELECT FOR SHARE is enough. That will give you > better concurrency, since it will block only updates and not > concurrent read transactions. When I mentioned my initial intuition up-thread, it was exactly that. In tests, I quickly came up with two issues that make a general solution harder to describe. One is that (in the upstream jargon) if TN and T1 are the same transaction, this totally fails to provide serializable behavior. (I can provide details for every case I describe if people want them, but really....) The other issue is that neither FOR SHARE or FOR UPDATE is allowed in some contexts which matter -- like subqueries and aggregate functions. I'm still trying to sort it all out, but I welcome all suggestions -- it's entirely possible that I'm missing something that will simplify the whole issue for me. Thanks, -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
