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
