Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> There's *three* transactions here. The first one is serializable, and
> reads the tuple. The second one is not serializable, and updates it. The
> third one is serializable and updates it again.
> The second transaction needs to copy the predicate lock held by the
> first transaction to the new row version, so that the third transaction
> that updates it again sees the lock.
> Or, we document that any non-serializable updates will break the
> serialization protection for any other transactions accessing the same rows.
Hmm. I wonder whether we need to have some sort of system-wide enable
flag for this. Unless you can show that the overhead is negligible
(and not having bothered to measure it is definitely not sufficient...)
I'm not excited about dragging down the performance of the entire
database on the off chance that somebody somewhere might be using SSI.
regards, tom lane
