Thread

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

    Keith Parks <emkxp01@mtcc.demon.co.uk> — 1999-12-17T23:13:55Z

    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.