Qingqing Zhou [EMAIL PROTECTED] writes:
Remove SpinLockAcquire_NoHoldoff() and related. Now SpinLockAcquire() will
not holdoff cancle/die interrupts. This will give cleaner and clearer
useage of spinlock and also save a few cycles.
Applied with some minor comment updates.
I noticed that
Tom Lane [EMAIL PROTECTED] wrote
I noticed that shmem.c holds ShmemIndexLock considerably longer than any
other spinlock is held, and across operations that could theoretically
fail (hashtable manipulations). This doesn't matter a lot in the Unix
code because only the postmaster ever
There is no LWLock protecting the spinlock in UnpinBuffer(), so we need do
so ourselves. I also checked other NoHoldOff spinlock, seems they are ok.
Regards,
Qingqing
Index: bufmgr.c
===
RCS file:
Qingqing Zhou [EMAIL PROTECTED] writes:
There is no LWLock protecting the spinlock in UnpinBuffer(),
I don't believe this is necessary, and if it is necessary the patch
is wrong anyway. Because the code uses _NoHoldoff, there won't be
any check of InterruptPending in that segment of code.
On Wed, 28 Dec 2005, Tom Lane wrote:
Because the code uses _NoHoldoff, there won't be any check of
InterruptPending in that segment of code.
I guess the danger I claimed may not really happen because of the
ImmediateInterruptOK variable. Since it is almost always false (except
reading inputs
So can you drop several lines on last post in list?
[ looks at code some more... ] Actually, I think this code thinks that
RESUME_INTERRUPTS() will do a CHECK_FOR_INTERRUPTS() if the count drops
to zero. Which it does not. (Perhaps it did at one time --- I don't
recall for sure --- but it
Tom Lane [EMAIL PROTECTED] wrote
So I'm thinking the right answer is to make all the spinlock macros be
the equivalent of the NoHoldoff case. It's reasonable for LWLockAcquire
to do a HOLD_INTERRUPTS, but I don't see the justification for doing it
at the spinlock level.
I agree on this.
Qingqing Zhou [EMAIL PROTECTED] writes:
I agree on this. But before changing it, we need to inspect those spinlocks
one by one to making sure two things (1) if there is out-of-line-call, make
sure no CHECK_FOR_INTERRUPTS(); (2) ImmediateInterruptsOK is false (99% sure
now).
I'm sure of
On Wed, 28 Dec 2005, Tom Lane wrote:
Qingqing Zhou [EMAIL PROTECTED] writes:
I agree on this. But before changing it, we need to inspect those spinlocks
one by one to making sure two things (1) if there is out-of-line-call, make
sure no CHECK_FOR_INTERRUPTS(); (2) ImmediateInterruptsOK is
