Rod Taylor <pg@rbt.ca> writes:
> On Fri, 2004-12-17 at 14:48 -0300, Alvaro Herrera wrote:
>> Does anyone remember why the patch was backed out? A pointer to the
>> archives would be most helpful.
> In order to prevent the ability for a domain, schema, etc. to be dropped
> while another process was using it, we were going to need to take a
> large number of new locks for nearly everything done (simple select
> statements included). I.e. Locks on all data types used in a simple
> select.
My recollection is that the patch either did, or intended to ultimately
do, locking on every single database object referenced by every query ---
datatypes, operators, functions, operator classes, schemas, you name it.
In an academic sense that's probably a good idea but the cost/benefit
ratio seemed much too high to me, and still does. What we actually need
in that area, I think, is a mechanism for invalidation and replanning of
cached query plans, which is not the same thing at all.
AFAICS locks on user/group IDs would only need to be taken in CREATE and
GRANT operations (other than CREATE/DROP USER/GROUP themselves), so the
locking costs should be far lower than what Rod was pointing towards
doing.
This doesn't necessarily affect the design of LOCKTAGs, however, only
what objects we actually choose to apply locking to.
regards, tom lane
