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

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

From
Keith Parks
Date:
wieck@debis.com (Jan Wieck)
>
>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.
>

Hi,

I reduced the tests to just 2 parallel, varchar and text.
(These 2 did seem to fail regularly)

Here's the results.

=============== Removing old ./tmp_check directory ... ================
=============== Create ./tmp_check directory           ================
=============== Installing new build into ./tmp_check  ================
=============== Initializing check database instance   ================
=============== Starting regression postmaster         ================
Regression postmaster is running - PID=28405 PGPORT=65432
=============== Creating regression database...        ================
CREATE DATABASE
=============== Installing PL/pgSQL...                 ================
=============== Running regression queries...          ================
parallel group1 (2 tests)            ...text  varchar           test varchar              ...  ok          test text
            ...  FAILED
 
=============== Terminating regression postmaster      ================
ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILES run_check.out
AND regress.out

To run the optional big test(s) too, type 'make bigcheck'
These big tests can take over an hour to complete
These actually are: numeric_big

** So only "text" failed, here's the differences.

bash-2.03$ ./checkresults 
======   text   ======
0a1,2
> NOTICE:  LockRelease: locktable lookup failed, no lock
> NOTICE:  LockRelease: locktable lookup failed, no lock

** Two notices.

bash-2.03$ cat tmp_check/log/postmaster.log
DEBUG:  Data Base System is starting up at Fri Dec 17 22:40:10 1999
DEBUG:  Data Base System was shutdowned at Fri Dec 17 22:40:09 1999
DEBUG:  CheckPoint record at (0, 776)
DEBUG:  Redo record at (0, 776); Undo record at (0, 0)
DEBUG:  NextTransactionId: 15907; NextOid: 0
DEBUG:  Invalid NextTransactionId/NextOid
DEBUG:  Data Base System is in production state at Fri Dec 17 22:40:10 1999
NOTICE:  LockRelease: locktable lookup failed, no lock
NOTICE:  LockRelease: locktable lookup failed, no lock
Smart Shutdown request at Fri Dec 17 22:40:24 1999
DEBUG:  Data Base System is shutting down at Fri Dec 17 22:40:24 1999
DEBUG:  Data Base System is shutdowned at Fri Dec 17 22:40:24 1999
bash-2.03$

Nothing unusual in the postmaster log. (except the notices)

** Look at the "text.sql" tests though, there's hardly enough
** scope for a couple of lock problems!!


-- *************testing built-in type text  ****************

SELECT 'this is a text string'::text = 'this is a text string'::text AS true;

SELECT 'this is a text string'::text = 'this is a text strin'::text AS false;

CREATE TABLE TEXT_TBL (f1 text);

INSERT INTO TEXT_TBL VALUES ('doh!');
INSERT INTO TEXT_TBL VALUES ('hi de ho neighbor');

SELECT '' AS two, * FROM TEXT_TBL;

** Now here's the odd thing, the notices are lines 1 and 2 in the
** results output file, apparently before the backend has done
** any real work.

NOTICE:  LockRelease: locktable lookup failed, no lock
NOTICE:  LockRelease: locktable lookup failed, no lock
QUERY: SELECT 'this is a text string'::text = 'this is a text string'::text AS t
rue;
true
----
t
(1 row)


** Maybe this is buffering? I don't know.

** I don't think I have the skills to find the problem but hope
** this may give someone a useful lead.

Keith.



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

From
wieck@debis.com (Jan Wieck)
Date:
>
> wieck@debis.com (Jan Wieck)
> >
> >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.
> >
>
> Hi,
>
> I reduced the tests to just 2 parallel, varchar and text.
> (These 2 did seem to fail regularly)
>
> Here's the results.
>
> =============== Removing old ./tmp_check directory ... ================
> =============== Create ./tmp_check directory           ================
> =============== Installing new build into ./tmp_check  ================
> =============== Initializing check database instance   ================
> =============== Starting regression postmaster         ================
> Regression postmaster is running - PID=28405 PGPORT=65432
> =============== Creating regression database...        ================
> CREATE DATABASE
> =============== Installing PL/pgSQL...                 ================
> =============== Running regression queries...          ================
> parallel group1 (2 tests)            ...
>  text  varchar
>            test varchar              ...  ok
>            test text                 ...  FAILED
> =============== Terminating regression postmaster      ================
> ACTUAL RESULTS OF REGRESSION TEST ARE NOW IN FILES run_check.out
> AND regress.out
>
> To run the optional big test(s) too, type 'make bigcheck'
> These big tests can take over an hour to complete
> These actually are: numeric_big
>
> ** So only "text" failed, here's the differences.
>
> bash-2.03$ ./checkresults
> ======   text   ======
> 0a1,2
> > NOTICE:  LockRelease: locktable lookup failed, no lock
> > NOTICE:  LockRelease: locktable lookup failed, no lock
>
> ** Two notices.
>
> bash-2.03$ cat tmp_check/log/postmaster.log
> DEBUG:  Data Base System is starting up at Fri Dec 17 22:40:10 1999
> DEBUG:  Data Base System was shutdowned at Fri Dec 17 22:40:09 1999
> DEBUG:  CheckPoint record at (0, 776)
> DEBUG:  Redo record at (0, 776); Undo record at (0, 0)
> DEBUG:  NextTransactionId: 15907; NextOid: 0
> DEBUG:  Invalid NextTransactionId/NextOid
> DEBUG:  Data Base System is in production state at Fri Dec 17 22:40:10 1999
> NOTICE:  LockRelease: locktable lookup failed, no lock
> NOTICE:  LockRelease: locktable lookup failed, no lock
> Smart Shutdown request at Fri Dec 17 22:40:24 1999
> DEBUG:  Data Base System is shutting down at Fri Dec 17 22:40:24 1999
> DEBUG:  Data Base System is shutdowned at Fri Dec 17 22:40:24 1999
> bash-2.03$
>
> Nothing unusual in the postmaster log. (except the notices)
>
> ** Look at the "text.sql" tests though, there's hardly enough
> ** scope for a couple of lock problems!!
>
>
> -- *************testing built-in type text  ****************
>
> SELECT 'this is a text string'::text = 'this is a text string'::text AS true;
>
> SELECT 'this is a text string'::text = 'this is a text strin'::text AS false;
>
> CREATE TABLE TEXT_TBL (f1 text);
>
> INSERT INTO TEXT_TBL VALUES ('doh!');
> INSERT INTO TEXT_TBL VALUES ('hi de ho neighbor');
>
> SELECT '' AS two, * FROM TEXT_TBL;
>
> ** Now here's the odd thing, the notices are lines 1 and 2 in the
> ** results output file, apparently before the backend has done
> ** any real work.
>
> NOTICE:  LockRelease: locktable lookup failed, no lock
> NOTICE:  LockRelease: locktable lookup failed, no lock
> QUERY: SELECT 'this is a text string'::text = 'this is a text string'::text AS t
> rue;
> true
> ----
> t
> (1 row)
>
>
> ** Maybe this is buffering? I don't know.
>
> ** I don't think I have the skills to find the problem but hope
> ** this may give someone a useful lead.
>
> Keith.
>
>
>


--

#======================================================================#
# 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) #

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

From
wieck@debis.com (Jan Wieck)
Date:
Keith Parks wrote:

> Hi,
>
> I reduced the tests to just 2 parallel, varchar and text.
> (These 2 did seem to fail regularly)

    That's   interesting!   So   it's   something  likely  to  be
    reproduceable.  Very good.

    But anyway - is it an older or a new bug? I'll try to use the
    parallel  test  on  a  6.5.* release the next days - maybe it
    tells us something more.


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) #