Skip site navigation (1) Skip section navigation (2)

Re: [WIP] The shared dependency patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rod Taylor <pg(at)rbt(dot)ca>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>,PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [WIP] The shared dependency patch
Date: 2004-12-17 18:50:06
Message-ID: 21708.1103309406@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Rod Taylor <pg(at)rbt(dot)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

In response to

pgsql-patches by date

Next:From: Jaime CasanovaDate: 2004-12-17 21:03:27
Subject: Re: From latin9 to sql_ascii??
Previous:From: Rod TaylorDate: 2004-12-17 18:01:28
Subject: Re: [WIP] The shared dependency patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group