RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock - Mailing list pgsql-hackers

From Keith Parks
Subject RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
Date
Msg-id 199912191045.KAA06358@mtcc.demon.co.uk
Whole thread Raw
Responses RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
List 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 by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] "ExecInitIndexScan: both left and right..." meaning?