From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [WIP] The shared dependency patch |
Date: | 2004-12-16 17:46:46 |
Message-ID: | 26134.1103219206@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> I was trying to find out if I could lock the user (and have the ALTER
> TABLE get a shared lock on the user before checking its existance, and
> the DROP USER get an exclusive lock which would be release at
> transaction end. So everything would remain consistant.) However the
> LOCKTAG does not have provisions to lock arbitrary objects, only
> relations (I could end up locking some completely unrelated table, I
> guess).
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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2004-12-16 18:06:24 | Re: Patch to add version numbers to libpq.rc |
Previous Message | Zeugswetter Andreas DAZ SD | 2004-12-16 16:18:25 | Re: Threading fix for AIX |