Re: Btree runtime recovery. Stuck spins. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Btree runtime recovery. Stuck spins.
Date
Msg-id 20532.981743015@sss.pgh.pa.us
Whole thread Raw
In response to Re: Btree runtime recovery. Stuck spins.  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Btree runtime recovery. Stuck spins.  (ncm@zembu.com (Nathan Myers))
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Our spinlocks don't go into an infinite test loop, right?  They back off
> and retest at random intervals.

Not very random --- either 0 or 10 milliseconds.  (I think there was
some discussion of changing that, but it died off without agreeing on
anything.)  The point though is that the code is tuned for use with
spinlocks protecting shared-memory data structures, where no one is
supposed to be holding the lock for long; so a short retry delay is
appropriate, and we don't need a very long time before declaring "stuck
spinlock" either.  This is not optimal for cases where someone may be
holding the lock for a good while, but detuning the code so that it
works less well for the shmem-structure case isn't the answer.

We need two different mechanisms.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Open 7.1 items
Next
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: Btree runtime recovery. Stuck spins.