Skip site navigation (1) Skip section navigation (2)

Re: How to handle waitingForLock in LockWaitCancel()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to handle waitingForLock in LockWaitCancel()
Date: 2001-03-05 06:16:08
Message-ID: 15997.983772968@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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?

> Probably it's due to the almost simultaneous arrival
> of multiple signals and the following patch seems to
> fix the bug. However I'm afraid that the change should
> cause another bug.

I do not like that change at *all*.  In the first place, how could it
stop whatever is causing the SEGV?  The waitingForLock flag is not
examined anywhere else, so unless things are already broken this cannot
have any effect.  In the second place, postponing the reset of the
flag has the potential for an infinite loop, because this routine is
called during error exit.  Suppose LockLockTable causes an elog(ERROR)?

I think we need to look harder to find the cause of the SEGVs you are
seeing.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Patrick DunfordDate: 2001-03-05 07:11:28
Subject: Getting unique ID through SQL
Previous:From: Lu RaymondDate: 2001-03-05 06:02:01
Subject: There is error at the examples in PL/pgSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group