| From: | Erik Jones <erik(at)myemma(dot)com> |
|---|---|
| To: | "Adam Rich" <adam(dot)r(at)indigodynamic(dot)com> |
| Cc: | "'andy'" <andy(at)squeakycode(dot)net>, <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Locking & concurrency - best practices |
| Date: | 2008-01-14 23:00:39 |
| Message-ID: | 843CD342-1FEF-49A7-9E01-A254A2174511@myemma.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Jan 14, 2008, at 4:57 PM, Adam Rich wrote:
>>
>> From what I can tell, this kind of roll-your-own application level
>> locking system is exactly what advisory locks are for. Search the
>> archives for the last couple of weeks as I remember someone posting
>> some really helpful functions to assist in using advisory locks.
>>
>> Erik Jones
>
> Yes & No... it depends on the lifetime of the locks you need. The new
> advisory locks in postgres only live for the duration of your session.
> The ones Andy describes will live past session end, connection end,
> even through database restarts. And if you're using replication or
> log shipping, the locks will be propagated to partner databases
> as well.
>
> If you need your locks to live past session end, the advisory locks
> won't help you.
Good point.
Erik Jones
DBA | Emma®
erik(at)myemma(dot)com
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2008-01-15 00:11:55 | Registration for PostgreSQL Conference East now open |
| Previous Message | Adam Rich | 2008-01-14 22:57:43 | Re: Locking & concurrency - best practices |