Thread: RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
"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? >> > >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.
> -----Original Message----- > From: Keith Parks [mailto:emkxp01@mtcc.demon.co.uk] > Sent: Sunday, December 19, 1999 7:45 PM > To: tgl@sss.pgh.pa.us; Inoue@tpf.co.jp > > "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? > >> > > > >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. > Thanks. I'm not sure my patch has no problem. May I dare to commit it to current tree ? Regards. Hiroshi Inoue Inoue@tpf.co.jp
> > >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. > > > > Thanks. > > I'm not sure my patch has no problem. > May I dare to commit it to current tree ? Commit it. If it produces other problems, at least we will know where to look. -- 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