Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> On 20.04.2011 17:26, Tom Lane wrote:
>> Why is predicate.c getting called at all when transaction_isolation is
>> not SERIALIZABLE? (Although the same crash happens when it is ...)
> Because another serializable transaction that reads/updates the tuple
> later needs to find the predicate lock acquired by the first
> transaction, even if the transaction in the middle isn't serializable.
Sorry, that argument doesn't pass the sniff test. If the transaction in
the middle isn't serializable, then it is not the same as the "first
transaction", which means that the first transaction is completed and
can no longer be holding any locks.
> It's unfortunate because it imposes a performance penalty to updates
> even if serializable transactions are not used. I don't think we ever
> measured the impact of this. :-(
This feature was sold to us on the grounds that it wouldn't impose any
performance penalty when not in use. Not having bothered to measure
the performance penalty isn't passing the sniff test either.
regards, tom lane