Thread: Re: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
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". What I will say is that the parallel running arrived at around the same time as the new psql and I didn't have an old version available to run the tests until sometime after. (had to download and build 6.5!) > > And if not, much better. Would show that running all tests > serialized had hidden a bug for a long time. > Quite possible, although something recent has aggrevated it somewhat ;-) Keith.
> 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". > > What I will say is that the parallel running arrived at around the > same time as the new psql and I didn't have an old version available > to run the tests until sometime after. (had to download and build 6.5!) Has anyone used CVS -D date to backtrack to the date it first started? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Re: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
From
wieck@debis.com (Jan Wieck)
Date:
Bruce Momjian wrote:
> > wieck@debis.com (Jan Wieck)
> > >Bruce Momjian wrote:
> > >
> > >> > NOTICE: LockRelease: locktable lookup failed, no lock
> > >> > (Otherwise the tests all passed.)
>
> Has anyone used CVS -D date to backtrack to the date it first started?
It also spit out a "Buffer leak" message once for me today.
Did not appear again. But be warned.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Keith Parks > > 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. Regards. 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?
regards, tom lane
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
>
> "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.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
Index: tcop/postgres.c
===================================================================
RCS file: /home/cvs/pgcurrent/backend/tcop/postgres.c,v
retrieving revision 1.8
diff -c -r1.8 postgres.c
*** tcop/postgres.c 1999/11/17 02:12:46 1.8
--- tcop/postgres.c 1999/12/19 02:35:12
***************
*** 1474,1480 **** on_shmem_exit(remove_all_temp_relations, NULL);
! parser_input = makeStringInfo(); /* initialize input buffer */ /* * Send this backend's cancellation
infoto the frontend.
--- 1474,1486 ---- on_shmem_exit(remove_all_temp_relations, NULL);
! {
! MemoryContext oldcontext;
!
! oldcontext = MemoryContextSwitchTo(TopMemoryContext);
! parser_input = makeStringInfo(); /* initialize input buffer */
! MemoryContextSwitchTo(oldcontext);
! } /* * Send this backend's cancellation info to the frontend.
Index: utils/init/postinit.c
===================================================================
RCS file: /home/cvs/pgcurrent/backend/utils/init/postinit.c,v
retrieving revision 1.6
diff -c -r1.6 postinit.c
*** utils/init/postinit.c 1999/11/22 01:28:26 1.6
--- utils/init/postinit.c 1999/12/19 02:50:29
***************
*** 546,551 ****
--- 546,554 ---- */ InitCatalogCache();
+ /* Could we start transaction here ? */
+ if (!bootstrap)
+ StartTransactionCommand(); /* * Set ourselves to the proper user id and figure out our postgres
*user id. If we ever add security so that we check for valid