Re: Locking & concurrency - best practices

On Jan 14, 2008 5:57 PM, Adam Rich <adam(dot)r(at)indigodynamic(dot)com> 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.

That's not really a lock (although it behaves like one). That's
simply a field in a table that says 'If i'm this do that otherwise do
that'. I don't know if there's a formal definition of locks, so I'm
loosely going to define them as things that protect access to the data
that are not in the data.

merlin