Re: pg_advisory_lock(bigint) vs. LOCK TABLE
От
Mark Roberts
Тема
Re: pg_advisory_lock(bigint) vs. LOCK TABLE
Дата
Msg-id
1216401746.26739.274.camel@localhost
Ответ на
Re: pg_advisory_lock(bigint) vs. LOCK TABLE (Alvaro Herrera)
Список
Дерево обсуждения
pg_advisory_lock(bigint) vs. LOCK TABLE Volkan YAZICI <yazicivo@ttmail.com>
Re: pg_advisory_lock(bigint) vs. LOCK TABLE Alvaro Herrera <alvherre@commandprompt.com>
Re: pg_advisory_lock(bigint) vs. LOCK TABLE Mark Roberts <mailing_lists@pandapocket.com>
Re: pg_advisory_lock(bigint) vs. LOCK TABLE Alvaro Herrera <alvherre@commandprompt.com>
Re: pg_advisory_lock(bigint) vs. LOCK TABLE Volkan YAZICI <yazicivo@ttmail.com>
Re: pg_advisory_lock(bigint) vs. LOCK TABLE Tom Lane <tgl@sss.pgh.pa.us>
On Thu, 2008-07-17 at 12:16 -0400, Alvaro Herrera wrote: > Volkan YAZICI wrote: > > Hi, > > > > What's the difference between below two queue implementations? > > They are two different lock spaces. pg_advisory_lock does not conflict > with regular system locks, whereas LOCK TABLE does. > > > -- > Alvaro Herrera http://www.CommandPrompt.com/ > The PostgreSQL Company - Command Prompt, Inc. > It also appears that advisory locks are tied to your session, where system locks are tied to your transaction. Also, lock table is a bit more forceful, because it will affect things that don't bother checking advisory locks (such as users, manual scripts, buggy applications, etc). Don't forget that you can use select for update another locking mechanism as well. Well, that's my take on it. -Mark
В списке pgsql-sql по дате отправления