On Thu, Jan 17, 2013 at 9:00 PM, Andres Freund <and...@2ndquadrant.com> wrote: >> > 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. > > I assumed it wasn't allowed, but didn't find where that happens at first > - I found it now though (c.f. SetLocktagRelationOid). > >> > 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. > > I don't know much about the locking code, you're probably right. I also > didn't look very far after finding the guilty commit. > > (reading code) > > Yes, I think you're right, that seems to be the actually correct fix. > > I am a bit worried that there are more such assumptions in the code, but > I didn't find any, but I really don't know that code.
I found two instances of this. See attached patch. Can you test whether this fixes it for you? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
fix-mydatabaseid-compare.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
