On Thu, Jan 17, 2013 at 6:22 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers