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

* 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."

* 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."