Re: Advisory locks seem rather broken
От | Tom Lane |
---|---|
Тема | Re: Advisory locks seem rather broken |
Дата | |
Msg-id | 15040.1336079321@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Advisory locks seem rather broken (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, May 3, 2012 at 3:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I'm inclined to say that you can PREPARE if your session holds a given >> advisory lock at either session or transaction level, but not both. >> This is a bit annoying but doesn't seem likely to be a real problem in >> practice, so thinking of a hack to support the case seems like more >> work than is justified. > I'd be more inclined to say that if you have a session-level lock, you > can't prepare, period. The bug report that started this investigation was precisely that preparing in the presence of a session-level lock failed, where it has worked in every release before 9.1; the prepare is supposed to simply ignore session locks. > Doesn't a rollback release session-level locks? No, it doesn't. Read http://www.postgresql.org/docs/devel/static/explicit-locking.html#ADVISORY-LOCKS (which could use some wordsmithing, but the specification is clear enough) regards, tom lane
В списке pgsql-hackers по дате отправления: