From: | "Adam Rich" <adam(dot)r(at)indigodynamic(dot)com> |
---|---|
To: | "'Erik Jones'" <erik(at)myemma(dot)com>, "'andy'" <andy(at)squeakycode(dot)net> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Locking & concurrency - best practices |
Date: | 2008-01-14 22:57:43 |
Message-ID: | 008001c85700$e0083570$a018a050$@r@indigodynamic.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>
> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Jones | 2008-01-14 23:00:39 | Re: Locking & concurrency - best practices |
Previous Message | Erik Jones | 2008-01-14 22:06:45 | Re: Locking & concurrency - best practices |