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 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. -- ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
