Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers