Re: Locking & concurrency - best practices

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Locking & concurrency - best practices
Дата
Msg-id b42b73150801142008u736b14ebr6deb74cf2517c45c@mail.gmail.com
обсуждение исходный текст
Ответ на Locking & concurrency - best practices  (Adam Rich <adam.r@indigodynamic.com>)
Список pgsql-general
On Jan 14, 2008 5:57 PM, Adam Rich <adam.r@indigodynamic.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

В списке pgsql-general по дате отправления:

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: Locking & concurrency - best practices
Следующее
От: "Adam Rich"
Дата:
Сообщение: Re: Locking & concurrency - best practices