On Fri, 2004-12-17 at 14:48 -0300, Alvaro Herrera wrote:
> On Thu, Dec 16, 2004 at 12:46:46PM -0500, Tom Lane wrote:
>
> > IIRC, Rod Taylor did some work on supporting locks for non-table objects
> > back around the beginning of the year. We rejected the patch for various
> > reasons but you might be able to adopt some of it.
>
> At the beggining of the past year, you mean? I found this:
>
> From: Rod Taylor <rbt@rbt.ca>
> To: PostgreSQL Patches <pgsql-patches@postgresql.org>
> Date: 15 Feb 2003 19:50:46 -0500
> Subject: Object (Domain) locking
>
> http://archives.postgresql.org/pgsql-patches/2003-02/msg00093.php
>
> In the archives, I see Bruce's message telling that it was applied, then
> it was backed out for untold reasons, and nothing else happenned.
>
> 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.
I don't remember if there was a specific reason given, but I've presumed
it was due to the above and the resulting performance hit.
> > Or you could do something like the pg_xactlock hack. Basically you need
> > a convention that identifies a LOCKTAG value as locking a particular
> > user, such that it can't exactly equal any lock on a regular relation.
>
> Hmm. The problem is that I need to lock users, groups and tablespaces,
> so a single value won't do. I could create three special values
> (pg_userlock, pg_grouplock, pg_tblspclock?), but at that point it
> seems something more general is needed, like maybe Rod's patch.
--
