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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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