"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> I propose here that we stop the release of lock before end of transaction.
>> I have been suffering from the early release of lock.
> If there's no objection,I would change UnlockRelation() to not release
> the specified lock except AccessShareLock.
After thinking about this some more, I am not convinced that it will buy
anything --- and it might possibly break things that work now. The
reason I'm not convinced about it is that we cannot apply the "don't
release locks till end of transaction" rule perfectly uniformly. You
already propose not to treat AccessShareLock that way, and Vadim seems
to think there will be other cases where we need to break the rule.
So we won't have a theoretically-clean situation anyway, and will have
to look at things case by case.
Can you give specific examples of cases that will be fixed?
For the most part I believe that we effectively protect updates to
system-table rows by holding AccessExclusiveLock on the associated user
relation. Locking the system table is just a means of preventing VACUUM
from running concurrently on the system table (and possibly moving the
tuple we want to update/delete). So I think releasing the system-table
lock is OK as long as we hold the user table lock till end of
transaction. VACUUM works fine with uncommitted tuples --- maybe we
should turn off its warning about them, at least in system relations?
There might be places where we are failing to hold user table locks long
enough, but those are just localized bugs and ought to be treated that way.
In any case, I do not think it's a good idea to put such a quick hack
in UnlockRelation(). UnlockRelation() should do what it's told. If we
want to do this, we should go around and change the heap_close() calls
to specify NoLock instead of whatever locks they specify now.
regards, tom lane
