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

"Hiroshi Inoue" <Inoue@tpf.co.jp>
>> 
>> wieck@debis.com (Jan Wieck)
>> >Bruce Momjian wrote:
>> >
>> >> > Keith Parks <emkxp01@mtcc.demon.co.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.