RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock

Поиск
Список
Период
Сортировка
От Keith Parks
Тема RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
Дата
Msg-id 199912191045.KAA06358@mtcc.demon.co.uk
обсуждение исходный текст
Ответы RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Список pgsql-hackers
"Hiroshi Inoue" <Inoue@tpf.co.jp>

>> 
>> "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?
>>
>
>I'm not sure it's possible or not.
>If startup sequence in InitPostgres() is changed,we may hardly
>find the place to start transaction during backend startup.
>
>Seems the unique place we could call StartTransacationCommand()
>during backend startup is between InitCatalogCahe() and InitUserId()
>in InitPostgres() now.
>I tried the following patch and it seems work at least now.
<snip>
Hiroshi
I concur, after application of this patch I've not had a single
lock NOTICE: error in the regression tests.

Good work.

Thanks,
Keith.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] "ExecInitIndexScan: both left and right..." meaning?