"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 eve
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 s
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) ImmediateInter
"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
"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
> 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 def
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 in
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. Fu
