Re: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock |
| Дата | |
| Msg-id | 11852.945473961@sss.pgh.pa.us обсуждение |
| Ответ на | RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
| Ответы |
RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
|
| Список | pgsql-hackers |
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> It seems that conflicts of the initialization of some backends cause
> above NOTICE messages.
> Those backends would use the same XIDTAGs for the same relations
> in case of LockAcquire()/LockRelease() because xids of those backends
> are'nt set before starting the first command. When one of the backend
> call LockReleaseAll(),it would release all together.
Oooh, that would nicely explain Keith's observation that it seems to
happen at backend startup. I guess we need to select an initial XID
earlier during startup than we now do?
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера