Re: SIREAD lock versus ACCESS EXCLUSIVE lock
От | Tom Lane |
---|---|
Тема | Re: SIREAD lock versus ACCESS EXCLUSIVE lock |
Дата | |
Msg-id | 13667.1307459476@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: SIREAD lock versus ACCESS EXCLUSIVE lock ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: SIREAD lock versus ACCESS EXCLUSIVE lock
|
Список | pgsql-hackers |
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > Tom Lane <tgl@sss.pgh.pa.us> wrote: >> If you don't believe that a catcache lookup will ever fail, I will >> contract to break the patch. > As you probably know by now by reaching the end of the thread, this > code is going away based on Heikki's arguments; but for my > understanding, so that I don't make a bad assumption in this area > again, what could cause the following function to throw an exception > if the current process is holding an exclusive lock on the relation > passed in to it? (I could be a heap or an index relation.) It > seemed safe to me, and I can't spot the risk on a scan of the called > functions. What am I missing? Out-of-memory. Query cancel. The attempted catalog access failing because it results in a detected deadlock. I could probably think of several more if I spent ten minutes on it; and that's not even considering genuine problem conditions such as a corrupted catalog index, which robustness demands that we not fall over completely for. You should never, ever assume that an operation as complicated as a catalog lookup can't fail. regards, tom lane
В списке pgsql-hackers по дате отправления: