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

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Keith Parks" <emkxp01(at)mtcc(dot)demon(dot)co(dot)uk>, <pgman(at)candle(dot)pha(dot)pa(dot)us>, <wieck(at)debis(dot)com>, <hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
Date: 1999-12-19 09:25:39
Message-ID: NDBBIJLOILGIKBGDINDFEELECBAA.Inoue@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)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 info to 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Keith Parks 1999-12-19 10:45:11 RE: [HACKERS] NOTICE: LockRelease: locktable lookup failed, no lock
Previous Message Tom Lane 1999-12-19 07:27:56 Re: [HACKERS] Re: [PATCHES] Lock