Re: How to handle waitingForLock in LockWaitCancel()

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to handle waitingForLock in LockWaitCancel()
Date: 2001-03-05 08:50:49
Message-ID: 3AA35369.D5DD9837@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > I sometimes encountered SEGV errors in my test case
> > when I canceled the execution.
>
> Can you provide backtraces from these SEGVs?
>

ISTM the backtrace isn't sufficient to figure out
how the error occured. As far as I see the error
was caused by other backends which terimnated
safely with the similar sequence of signals.
I have a (about 7MB) postmaster log with the
trace_locks option on. I could send it to you
if you want. Note that I applied the following
patch to debug my suspicion. In addition I added
an SegvException Handler to postgres.c.

diff -c -r1.35 proc.c
*** storage/lmgr/proc.c 2001/01/29 10:00:58 1.35
--- storage/lmgr/proc.c 2001/03/05 07:56:56
***************
*** 327,332 ****
--- 327,334 ----
if (!waitingForLock)
return false;

+ if (MyProc->links.next != INVALID_OFFSET)
+ fprintf(stderr, "LockWaitCancel pid=%d must
RemoveFromWaitQueue\n", MyProc->pid);
waitingForLock = false;

/* Turn off the deadlock timer, if it's still running (see
ProcSleep) */

And the backtrace is as follows.

#0 0x40130db7 in __libc_pause ()
#1 0x811981c in SegvExceptionHandler (postgres_signal_arg=11)
at postgres.c:966
#2 <signal handler called>
#3 0x8482 in ?? ()
#4 0x811547e in ProcLockWakeup (lockMethodTable=0x8204260,
lock=0x409d6bdc)
at proc.c:771
#5 0x8114500 in LockReleaseAll (lockmethod=1, proc=0x409d9d20,
allxids=1 '\001', xid=0) at lock.c:1438
#6 0x81150b4 in ProcKill () at proc.c:446
#7 0x810df3b in shmem_exit (code=0) at ipc.c:187
#8 0x810dead in proc_exit (code=0) at ipc.c:146
#9 0x815891e in elog (lev=1, fmt=0x81aee71 "The system is shutting
down")
at elog.c:465
#10 0x8119927 in ProcessInterrupts () at postgres.c:1039
#11 0x810c526 in s_lock (lock=0x40195016 "\001", file=0x81ac4ea
"spin.c",
line=156) at s_lock.c:140
#12 0x810fec7 in SpinAcquire (lockid=6) at spin.c:156
#13 0x8114f74 in LockWaitCancel () at proc.c:349
#14 0x81197d8 in die (postgres_signal_arg=15) at postgres.c:947
#15 <signal handler called>
#16 0x8482 in ?? ()
#17 0x400ffcd4 in _IO_old_file_xsputn (f=0x81ce3a8, data=0xbfffc288,
n=49)
at oldfileops.c:294
#18 0x400f1acf in buffered_vfprintf (s=0x81ce3a8,
format=0x81adba0 "LockWaitCancel pid=%d must RemoveFromWaitQueue\n",
args=0xbfffe8c8) at vfprintf.c:1767
#19 0x400ed5cc in _IO_vfprintf (s=0x81ce3a8,
format=0x81adba0 "LockWaitCancel pid=%d must RemoveFromWaitQueue\n",
ap=0xbfffe8c8) at vfprintf.c:1029
#20 0x400f4f03 in fprintf (stream=0x81ce3a8,
format=0x81adba0 "LockWaitCancel pid=%d must RemoveFromWaitQueue\n")
at fprintf.c:32
#21 0x8114f25 in LockWaitCancel () at proc.c:331
#22 0x811988c in QueryCancelHandler (postgres_signal_arg=2) at
postgres.c:993
#23 <signal handler called>
#24 0x8482 in ?? ()
#25 0x810e22b in IpcSemaphoreLock (semId=32768, sem=8, interruptOK=1
'\001')
at ipc.c:423
#26 0x811530f in ProcSleep (lockMethodTable=0x8204260, lockmode=4,
lock=0x409d726c, holder=0x409d7e08) at proc.c:669
#27 0x8112eb3 in WaitOnLock (lockmethod=1, lockmode=4, lock=0x409d726c,
holder=0x409d7e08) at lock.c:995
#28 0x81124d8 in LockAcquire (lockmethod=1, locktag=0xbfffeb5c,
xid=373273,
lockmode=4) at lock.c:779
#29 0x8111372 in XactLockTableWait (xid=373282) at lmgr.c:309
#30 0x80cf5ef in EvalPlanQual (estate=0x8260a0c, rti=1, tid=0xbfffebe0)
at execMain.c:1751
#31 0x80ceebd in ExecReplace (slot=0x8260bec, tupleid=0xbfffec3c,
estate=0x8260a0c) at execMain.c:1449
#32 0x80ceb2e in ExecutePlan (estate=0x8260a0c, plan=0x8260964,
operation=CMD_UPDATE, numberTuples=0,
direction=ForwardScanDirection,
destfunc=0x82611c0) at execMain.c:1119
#33 0x80cdf73 in ExecutorRun (queryDesc=0x82609f0, estate=0x8260a0c,
feature=3, count=0) at execMain.c:233
#34 0x811ac2b in ProcessQuery (parsetree=0x825379c, plan=0x8260964,
dest=Remote) at pquery.c:297
#35 0x811964b in pg_exec_query_string (
query_string=0x8253400 "update branches set bbalance = bbalance +
687 where bid = 1", dest=Remote, parse_context=0x8237640) at
postgres.c:810
#36 0x811a712 in PostgresMain (argc=9, argv=0xbfffee9c, real_argc=12,
real_argv=0xbffff774, username=0x82104b9 "reindex") at
postgres.c:1900
#37 0x80ffb03 in DoBackend (port=0x8210250) at postmaster.c:2080
#38 0x80ff6fa in BackendStartup (port=0x8210250) at postmaster.c:1863
#39 0x80fea96 in ServerLoop () at postmaster.c:963
#40 0x80fe527 in PostmasterMain (argc=12, argv=0xbffff774) at
postmaster.c:662
#41 0x80df8e9 in main (argc=12, argv=0xbffff774) at main.c:149

Regards,
Hiroshi Inoue

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2001-03-05 09:46:50 AW: WAL & RC1 status
Previous Message Vic 2001-03-05 08:33:35 Oops! Its bug in parser????