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

"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
>>
>> wieck(at)debis(dot)com (Jan Wieck)
>> >Bruce Momjian wrote:
>> >
>> >> > Keith Parks <emkxp01(at)mtcc(dot)demon(dot)co(dot)uk> writes:
>> >> > > Since the new parallel regression tests I've always had a few
>> >> > > lock NOTICE messages like the following.
>> >> >
>> >> > Interesting --- I had not run the parallel test for a while,
>> >> > but I tried it just now and got half a dozen of these:
>> >> > NOTICE: LockRelease: locktable lookup failed, no lock
>> >> > (Otherwise the tests all passed.)
>> >> >
>> >> > Something's been broken fairly recently. Does anyone have an
>> >> > idea what changed?
>> >>
>> >> Good question. I can't imagine what it would be. We didn't do much,
>> >> and parallel regression is not that old.
>> >
>> >
>> > Also, I used it after another dozen times without. Now I see
>> > them too. So I assume it was a recent change that introduced
>> > the problem.
>>
>> I'm not sure it's that recent, I think I've had 1 or 2 such errors
>> ever since I've been running the "runcheck".
>>
>
>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.
>
>If we set pid member of XIDTAG to the pid of each backend
>,we are able to distinguish XIDTAGs.
>But there may be some reasons that the member is used only for
>userlock.

I've just run a full set of tests and you're right, all the
NOTICE:'s are in the init phase, before any queries are run.

I hope this makes it easier for someone to fix ;-)

Keith.