Tom Lane wrote:
> Actually ... wait a minute. The proposed hack covers the case of
> SELECT FOR SHARE followed by SELECT FOR UPDATE within a subtransaction.
> But what about SELECT FOR SHARE followed by an actual UPDATE (or DELETE)?
>
> We certainly don't want to mark the UPDATE/DELETE as having been carried
> out by the upper transaction, but there's no way we can record the
> UPDATE while still remembering the previous share-lock.
>
> So I think I'm back to the position that we should throw an error here.
Yeah. Even without a real update, I just figured you can't upgrade a
shared lock held by an arbitrarily chosen parent to an exclusive lock.
If that subxid aborts, and if any of the parents of that subtransaction
held the shared lock, that lock would be released incorrectly. Which is
essentially the same problem we began with.
Let's throw an error for now. We have to come back to this in 8.3, I think.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
