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

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Keith Parks
>
> 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.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp