>>> "Robert Haas" <robertmhaas@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
