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

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>

>>
>> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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.