On 20.04.2011 17:51, Tom Lane wrote:
> 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.
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
