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 <[EMAIL PROTECTED]>
> To: PostgreSQL Patches <[EMAIL PROTECTED]>
> 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

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.

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to