I'm thinking of making two small changes in LockAcquire's behavior:
1. Bogus parameters (in particular an invalid locktable id) should
result in elog(ERROR), not a failure return. The existing API makes
it impossible to tell the difference between an invalid parameter
and an unobtainable lock. This change will eliminate the need for
testing the return value at all in most of the call sites.
2. Instead of a boolean result, return a three-state result, along
the lines of
0: could not acquire lock immediately, and dontWait is true
1: successful lock acquisition
2: incremented lock count of a lock we already hold
The reason for doing this is that in LockRelation, we can skip the
call to AcceptInvalidationMessages() if we are re-acquiring a lock
already held. This is a very common scenario --- in particular,
the parser, rewriter, and executor successively acquire the same
lock on each table mentioned in a query. The "extra" locks are needed
in scenarios where a table reference comes from a rewrite rule, or
when executing a plan that was computed in a prior transaction; so
I don't think we can remove them entirely. But we can reduce the
number of calls to AcceptInvalidationMessages, which is starting to
look like a hotspot in profiles of simple queries.
Any objections?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
