Re: [PATCHES] Minor fix in lwlock.c

Tom Lane [EMAIL PROTECTED] writes Maybe we *should* make it a PANIC. Thoughts? Reasonable. Since this should *never* happen. Once happened, that's means we have a serious bug in our design/coding. Regards, Qingqing ---(end of broadcast)---

Re: [PATCHES] Minor fix in lwlock.c

Qingqing Zhou [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes Maybe we *should* make it a PANIC. Thoughts? Reasonable. Since this should *never* happen. Once happened, that's means we have a serious bug in our design/coding. Plan C would be something like if

Re: [PATCHES] Minor fix in lwlock.c

Tom Lane [EMAIL PROTECTED] writes Plan C would be something like if (num_held_lwlocks = MAX_SIMUL_LWLOCKS) { release the acquired lock; elog(ERROR, too many LWLocks taken); } But we couldn't just call LWLockRelease, since it expects the lock to be recorded in held_lwlocks[]. We'd have

Re: [PATCHES] Minor fix in lwlock.c

Qingqing Zhou [EMAIL PROTECTED] writes: /* Unlock semaphores first */ while (extraWaits-- 0) PGSemaphoreUnlock(proc-sem); /* Add the lock into my list then. * If a process is in exiting status, it could use the reserved lwlocks */ reserved = proc_exit_inprogress? 0 :

Re: [PATCHES] Minor fix in lwlock.c

Actually, on further thought, there's a really simple solution that we've used elsewhere: make sure you have the resource you need *before* you get into the critical section of code. I've applied the attached revised patch. regards, tom lane ***

Re: [PATCHES] Minor fix in lwlock.c

Tom Lane [EMAIL PROTECTED] writes Actually, on further thought, there's a really simple solution that we've used elsewhere: make sure you have the resource you need *before* you get into the critical section of code. I've applied the attached revised patch. Oh, that's the one - why didn't

Re: [PATCHES] Minor fix in lwlock.c

Qingqing Zhou [EMAIL PROTECTED] writes: The chance that num_held_lwlocks is beyond MAX_SIMUL_LWLOCKS is similar to the chance that failed to grasp a spinlock in 1 minute, so they should be treated in the same way. This is mainly to prevent programming error (e.g., forget to release the

Re: [PATCHES] Minor fix in lwlock.c

Tom Lane [EMAIL PROTECTED] writes I don't see any reason to think we'd be unable to recover normally from such a bug --- do you? I guess the problem is here: /* * Fix the process wait semaphore's count for any absorbed wakeups. */ while (extraWaits-- 0) PGSemaphoreUnlock(proc-sem);

Re: [PATCHES] Minor fix in lwlock.c

Qingqing Zhou [EMAIL PROTECTED] writes: I guess the problem is here: /* * Fix the process wait semaphore's count for any absorbed wakeups. */ while (extraWaits-- 0) PGSemaphoreUnlock(proc-sem); Mmm. Could be a problem, but the chances of having extraWaits0 is really pretty small.

Re: [PATCHES] Minor fix in lwlock.c

Tom Lane [EMAIL PROTECTED] writes The alternative would be to move the Unlock loop in front of the addition of the LWLock to held_lwlocks[], but I think that cure is probably worse than the disease --- the chance of an error during Unlock seems nonzero. Another alternative might use