Re: FATAL: lock AccessShareLock on object 0/1260/0 is already held

Robert Haas <robertmhaas@gmail.com> writes:
> After spending some time staring at the code, I do have one idea as to
> what might be going on here.  When a backend is terminated,
> ShutdownPostgres() calls AbortOutOfAnyTransaction() and then
> LockReleaseAll(USER_LOCKMETHOD, true).  The second call releases all
> user locks, and the first one (or so we suppose) releases all normal
> locks as part of aborting the transaction.  But what if there's no
> transaction in progress?  In that case, AbortOutOfAnyTransaction()
> won't do anything - which is fine as far as transaction-level locks
> go, because we shouldn't be holding any of those anyway if there's no
> transaction in progress.  However, if we hold a session-level lock at
> that point, then we'd orphan it.  We don't make much use of session
> locks.  As far as I can see, they are used by (1) VACUUM, (2) CREATE
> INDEX CONCURRENTLY, (3) ALTER DATABASE .. SET TABLESPACE, and (4) on
> standby servers, redo of DROP DATABASE actions.  Any chance one of
> those died or was killed off around the time this happened?

I don't believe this theory at all, because if that were the issue,
we'd have heard about it long since.  The correct theory has to involve
a very-little-used triggering condition.  At the moment I'm wondering
about advisory (userspace) locks ... Dave, do your apps use any of those?
        regards, tom lane