"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.


Sun, 19 Dec 1999 10:45:11 +0000 (GMT)
Keith Parks <emkxp01@mtcc.demon.co.uk>
RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock 
> -----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


Mon, 20 Dec 1999 11:24:51 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock 
> > >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, Pennsylvania 19026

Sun, 19 Dec 1999 21:35:37 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock