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
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 |