| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Chris Bowlby <excalibur(at)accesswave(dot)ca> |
| Cc: | pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proper Method for using LockAcquire |
| Date: | 2006-07-13 18:49:47 |
| Message-ID: | 18117.1152816587@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Chris Bowlby <excalibur(at)accesswave(dot)ca> writes:
> I've been working on a small module that I will be pluging into my
> local PostreSQL 8.x database and am in need of doing some table locking.
> At this time, I've used various other examples to no avail and was
> wondering what the proper method for aquiring a table lock within the
> module would be?
You should not be touching locks at any level lower than lmgr.c's
exports; eg LockRelation() not LockAcquire(). The LockAcquire API
is not as stable.
Usually people take a relation lock in combination with opening the rel
in the first place, ie, specify the desired lock to heap_open or
relation_open or one of their variants. If you apply LockRelation() to
an already-opened rel then you need to be worrying about possible
deadlocks due to lock upgrading.
Also, 90% of the time you probably don't want to release the lock
explicitly at all; leave it to be held until transaction end.
Early release violates the 2PL principle, so you need to analyze
things pretty carefully to determine if it's safe.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2006-07-13 18:53:05 | Re: Proper Method for using LockAcquire |
| Previous Message | Marc G. Fournier | 2006-07-13 18:48:49 | Re: Three weeks left until feature freeze |