On Thu, Jan 17, 2013 at 6:22 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> That only made the bug more visible - the real bug is somewhere
> else. Which makes it even scarrier, the bug was in in the fast path
> locking patch from the start...
>
> It assumes conflicting fast path locks can only ever be in the same
> database as the the backend transfering the locks to itself. But thats
> obviously not true for the startup process which is in no specific
> database.
Ugh.
> I think it might also be a dangerous assumption for shared objects?
Locks on shared objects can't be taken via the fast path. In order to
take a fast-path lock, a backend must be bound to a database and the
locktag must be for a relation in that database.
> A patch minimally addressing the is attached, but it only addresses part
> of the problem.
Isn't the right fix to compare proc->databaseId to
locktag->locktag_field1 rather than to MyDatabaseId? The subsequent
loop assumes that if the relid matches, the lock tag is an exact
match, which will be correct with that rule but not the one you
propose.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company