Simon Riggs wrote:
> On Wed, 2009-09-23 at 12:07 +0300, Heikki Linnakangas wrote:
>> seems to be broken
>
> Agreed.
Looking at the relation lock stuff a bit more...
When someone tries to acquire an AccessExclusiveLock, but can't get it
immediately, we sleep while holding RecoveryInfoLock. That doesn't
affect normal queries, but it will in turn block any attempt to get a
running-xacts snapshot, and will thus block checkpoint from finishing.
It could take a very long time until you get an AccessExclusiveLock on a
busy table, so that seems pretty bad. I think we need to think a bit
harder about that locking.
The problem becomes a lot easier if we accept that it's OK to have a
lock included in the running-xacts snapshot and also appear in a
XLOG_RELATION_LOCK record later. The standby should handle that
gracefully already. If we just remove RecoveryInfoLock, that can happen,
but it still won't be possible for a lock to be missed out which is what
we really care about.
Rather than keep the numHeldLocks counters per-proc in proc array, I
think it would be simpler to have a single (or one per lock partition)
counter in shared memory in lock.c. It's just an optimization to make it
faster to find out that there is no loggable AccessExclusiveLocks in the
system, so it really rather belongs into the lock manager.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
