Re: Locking & concurrency - best practices

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.

In response to

Responses

Browse pgsql-general by date

  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