Argh! I can't reproduce this:

NOTICE:  Message from PostgreSQL backend:
        The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory.
        I have rolled back the current transaction and am going to terminate your database system connection and exit.
        Please reconnect to the database system and repeat your query.
NOTICE:  Message from PostgreSQL backend:
        The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory.
        I have rolled back the current transaction and am going to terminate your database system connection and exit.
        Please reconnect to the database system and repeat your query.
NOTICE:  Message from PostgreSQL backend:
        The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory.
        I have rolled back the current transaction and am going to terminate your database system connection and exit.
        Please reconnect to the database system and repeat your query.
pqReadData() -- backend closed the channel unexpectedly.
        This probably means the backend terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.




Basically I was running two instances of psql, in one I issued:

          one                              two

begin;
lock data;  -- some table
                                      lock data;^C -- cancel
                                      select * from data;^C -- cancel
end;
                                      
                                      lock data;^C -- HUNG then aborted

It's annoying that I can't seem to reproduce this, and I know LOCKs
are only to be requested during a transaction, but it did happen.

thanks,
-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."

Thu, 11 May 2000 10:35:18 -0700
Alfred Perlstein <bright@wintelcom.net>
Orphaned locks in 7.0?
Alfred Perlstein <bright@wintelcom.net> writes:
> Argh! I can't reproduce this:

Was a core file left behind?  Can you get a backtrace from it?

			regards, tom lane

Thu, 11 May 2000 13:54:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Orphaned locks in 7.0? 
* Tom Lane <tgl@sss.pgh.pa.us> [000511 11:26] wrote:
> Alfred Perlstein <bright@wintelcom.net> writes:
> > Argh! I can't reproduce this:
> 
> Was a core file left behind?  Can you get a backtrace from it?

I enabled assertion checking and debug, here we go:

Core was generated by `postgres'.
Program terminated with signal 6, Abort trap.
Reading symbols from /usr/lib/libcrypt.so.2...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libreadline.so.4...done.
Reading symbols from /usr/lib/libncurses.so.5...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x48281fd8 in kill () from /usr/lib/libc.so.4
(gdb) bt
#0  0x48281fd8 in kill () from /usr/lib/libc.so.4
#1  0x482bb4a2 in abort () from /usr/lib/libc.so.4
#2  0x8143c53 in ExcAbort () at excabort.c:27
#3  0x8143bd2 in ExcUnCaught (excP=0x81a5708, detail=0, data=0x0, 
    message=0x8189040 "!((result->nHolding > 0) && (result->holders[lockmode] >= 0))") at exc.c:170
#4  0x8143c19 in ExcRaise (excP=0x81a5708, detail=0, data=0x0, 
    message=0x8189040 "!((result->nHolding > 0) && (result->holders[lockmode] >= 0))") at exc.c:187
#5  0x8143308 in ExceptionalCondition (
    conditionName=0x8189040 "!((result->nHolding > 0) && (result->holders[lockmode] >= 0))", exceptionP=0x81a5708, detail=0x0, fileName=0x8188e0c "lock.c", 
    lineNumber=617) at assert.c:73
#6  0x810422e in LockAcquire (lockmethod=1, locktag=0xbfbfe808, lockmode=1)
    at lock.c:617
#7  0x81036d1 in LockRelation (relation=0x8471ba0, lockmode=1) at lmgr.c:148
#8  0x8071957 in heap_open (relationId=1249, lockmode=1) at heapam.c:551
#9  0x813e329 in SearchSysCache (cache=0x847c018, v1=8490746, v2=136106584, 
    v3=0, v4=0) at catcache.c:1009
#10 0x8142210 in SearchSysCacheTuple (cacheId=4, key1=8490746, key2=136106584, 
    key3=0, key4=0) at syscache.c:532
#11 0x80cfc5d in make_var (pstate=0x81cd020, relid=8490746, 
    refname=0x81cd180 "data", attrname=0x81cd258 "referer") at parse_node.c:202
#12 0x80d12be in expandAll (pstate=0x81cd020, relname=0x81cd180 "data", 
    ref=0x81cd158, this_resno=0x81cd020) at parse_relation.c:408
#13 0x80d25b8 in ExpandAllTables (pstate=0x81cd020) at parse_target.c:444
#14 0x80d213b in transformTargetList (pstate=0x81cd020, targetlist=0x81ccea8)
    at parse_target.c:139
#15 0x80c0ef6 in transformSelectStmt (pstate=0x81cd020, stmt=0x81ccf50)
    at analyze.c:1423
#16 0x80bf780 in transformStmt (pstate=0x81cd020, parseTree=0x81ccf50)
    at analyze.c:238
#17 0x80bf3c2 in parse_analyze (pl=0x81cd008, parentParseState=0x0)
    at analyze.c:75
#18 0x80cafa1 in parser (str=0x8469018 "select * from data;", typev=0x0, 
    nargs=0) at parser.c:64
#19 0x8109923 in pg_parse_and_rewrite (
    query_string=0x8469018 "select * from data;", typev=0x0, nargs=0, 
    aclOverride=0 '\000') at postgres.c:395
#20 0x8109bcb in pg_exec_query_dest (
    query_string=0x8469018 "select * from data;", dest=Remote, aclOverride=0)
    at postgres.c:580
#21 0x8109b91 in pg_exec_query (query_string=0x8469018 "select * from data;")
    at postgres.c:562
#22 0x810ab4a in PostgresMain (argc=7, argv=0xbfbff138, real_argc=8, 
    real_argv=0xbfbffb98) at postgres.c:1590
#23 0x80f00d6 in DoBackend (port=0x8463000) at postmaster.c:2006
#24 0x80efc7d in BackendStartup (port=0x8463000) at postmaster.c:1775
#25 0x80eeea1 in ServerLoop () at postmaster.c:1035
#26 0x80ee88a in PostmasterMain (argc=8, argv=0xbfbffb98) at postmaster.c:723
#27 0x80bf327 in main (argc=8, argv=0xbfbffb98) at main.c:93
#28 0x80633d5 in _start ()

(gdb) up
#6  0x810422e in LockAcquire (lockmethod=1, locktag=0xbfbfe808, lockmode=1)
    at lock.c:617
617                     Assert((result->nHolding > 0) && (result->holders[lockmode] >= 0));
(gdb) list
612                     XID_PRINT("LockAcquire: new", result);
613             }
614             else
615             {
616                     XID_PRINT("LockAcquire: found", result);
617                     Assert((result->nHolding > 0) && (result->holders[lockmode] >= 0));
618                     Assert(result->nHolding <= lock->nActive);
619             }
620     
621             /* ----------------
(gdb) 

Seems to be what brought things down.

If you need anything else, let me know.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."

Thu, 11 May 2000 11:47:00 -0700
Alfred Perlstein <bright@wintelcom.net>
Re: Orphaned locks in 7.0?
* Hiroshi Inoue <Inoue@tpf.co.jp> [000515 02:07] wrote:
> > -----Original Message-----
> > From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
> > Behalf Of Alfred Perlstein
> > 
> > Basically I was running two instances of psql, in one I issued:
> > 
> >           one                              two
> > 
> > begin;
> > lock data;  -- some table
> >                                       lock data;^C -- cancel
> >                                       select * from data;^C -- cancel
> > end;
> >                                       
> >                                       lock data;^C -- HUNG then aborted
> > 
> > It's annoying that I can't seem to reproduce this, and I know LOCKs
> > are only to be requested during a transaction, but it did happen.
> >
> 
> Could the following example explain your HUNG problem ?
> 
> Session-1
> 	# begin;
> 	BEGIN
> 	=# lock t;
> 	LOCK TABLE
> 
> Session-2
> 	=# begin;
> 	BEGIN
> 	=# lock t; 
> 	[blocked] ^C
> 	Cancel request sent
> 	ERROR:  Query cancel requested while waiting lock
> 	reindex=# select * from t;
> 	[blocked]
> 
> Session-1
> 	=# commit;
> 	COMMIT
> 
> Session-2
> 	ERROR:  LockRelation: LockAcquire failed
> 	=# abort;
> 	ROLLBACK
> 	=# lock t;
> 	[blocked]

That looks pretty much like the sequence of events that lead up to
the problem, the problem is that I was just manually testing out
the way locks work and didn't write down the exact steps I took.

This is probably exactly the right steps though.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."

Mon, 15 May 2000 09:23:58 -0700
Alfred Perlstein <bright@wintelcom.net>
Re: Orphaned locks in 7.0?