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

> -----Original Message-----
> From: Keith Parks [mailto:emkxp01(at)mtcc(dot)demon(dot)co(dot)uk]
> Sent: Sunday, December 19, 1999 7:45 PM
> To: tgl(at)sss(dot)pgh(dot)pa(dot)us; Inoue(at)tpf(dot)co(dot)jp
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
>
> >>
> >> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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(at)tpf(dot)co(dot)jp