paolo romano <paolo.romano@yahoo.it> writes:
> Anyway, again in theory, if one wanted to minimize logging overhead for shared locks, one might adopt a different
treatmentfor (i) regular shared locks (i.e. locks due to plain reads not requiring durability in case of 2PC) and (ii)
sharedlocks held because some SQL command is referencing a tuple via a FK, which have to be persisted until the 2-nd
2PCphase (There is no any other scenario in which you *must* persist shared locks, is there?)
I can't see any basis at all for asserting that you don't need to
persist particular types of locks. In the current system, a multixact
lock might arise from either FK locking, or a user-issued SELECT FOR SHARE.
In either case it's possible that the lock was taken to guarantee the
integrity of a data change made somewhere else. So we can't release it
before commit.
regards, tom lane