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 по дате отправления: