[EMAIL PROTECTED] writes: > [ there isn't any locking associated with namespaces ]
Nor any other kind of object except tables... There have been some discussions about fixing this, but the idea has bogged down in concerns about performance and possible deadlocks. To be completely correct, a query as simple as select * from foo where col1 = 42; would have to obtain locks on not only table foo, but - foo's namespace - the integer '=' operator - the int4eq() function underlying the operator - the namespace(s) of the operator and function - any other namespaces preceding these in your search path (else someone might insert a new foo or '=' that should take precedence in your query) - maybe also some locks on data types so you can see that we'd probably be talking at least one order of magnitude increase in the traffic through the lock manager, which is already something of a bottleneck :-(. Plus this traffic would be very heavily concentrated on a few popular objects, such as the pg_catalog schema. The lock manager is not really designed to have large numbers of processes taking out locks on a single object, and would probably need considerable work to make the performance acceptable. The concern about extra deadlocks is more hypothetical, but I think there would definitely be some risk there, with so many more lock requests flying around the system. All in all it looks like a lot of work to solve a problem that doesn't affect very many people. I can't recall many complaints other than yours ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster