Thread

1. RE: Lock on arbitrary string feature

   Mikheev, Vadim <vmikheev@sectorbase.com> — 2001-01-11T17:20:19Z

   > In contrast the current alternatives appear to be either LOCK 
   > the entire table (preventing ALL inserts and selects),
   
   SHARE ROW EXCLUSIVE mode doesn't prevent selects...
   
   > or to create a UNIQUE constraint (forcing complete rollbacks
   > and restarts in event of a collision :( ).
   
   Hopefully, savepoints will be in 7.2
   
   > Any comments, suggestions or tips would be welcome. It looks 
   > like quite a complex thing to do - I've only just started
   > looking at the postgresql internals and the lock manager.
   
   It's very easy to do (from my PoV -:)) We need in yet another
   pseudo table like one we use in XactLockTableInsert/XactLockTableWait
   - try to look there...
   
   Vadim
   
   

2. RE: Lock on arbitrary string feature

   Myron Scott <mscott@sacadia.com> — 2001-01-11T18:14:25Z

   
   > Has anyone any input to offer on adding an arbitrary locking feature?
   
   Have you tried user locks?  They don't block and span transactions but
   maybe you can work this out in your application.
   
   User locks are not in the parser but there is an  add on module 
   that is in the contrib dir. Maybe that will work for you.
   
   
   
   Myron Scott
   mkscott@sacadia.com
   
   
   
   
   

3. RE: Lock on arbitrary string feature

   Lincoln Yeoh <lyeoh@pop.jaring.my> — 2001-01-12T01:43:16Z

   At 09:20 AM 11-01-2001 -0800, Mikheev, Vadim wrote:
   >> In contrast the current alternatives appear to be either LOCK 
   >> the entire table (preventing ALL inserts and selects),
   >
   >SHARE ROW EXCLUSIVE mode doesn't prevent selects...
   
   Sorry, I meant all inserts and selects on the locked table. At least so far
   it seems to block those selects in 7.0.3 (I hope it does in all cases! If
   not uhoh!).
   
   >> or to create a UNIQUE constraint (forcing complete rollbacks
   >> and restarts in event of a collision :( ).
   >
   >Hopefully, savepoints will be in 7.2
   
   Yep that'll solve some things. Still think the getlock feature will be very
   handy in many other cases.
   
   BTW would there be a significant performance/resource hit with savepoints?
   
   >> Any comments, suggestions or tips would be welcome. It looks 
   >> like quite a complex thing to do - I've only just started
   >> looking at the postgresql internals and the lock manager.
   >
   >It's very easy to do (from my PoV -:)) We need in yet another
   >pseudo table like one we use in XactLockTableInsert/XactLockTableWait
   >- try to look there...
   
   Thanks!
   
   I think by the time I succeed Postgresql will be version 7.2 or even 8 :).
   
   Cheerio,
   Link.