Thread

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

Keith Parks <emkxp01@mtcc.demon.co.uk> — 1999-12-19T10:45:11Z

"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.