On Jan 14, 2008 5:57 PM, Adam Rich <adam.r@xxxxxxxxxxxxxxxxx> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
