Re: Btree runtime recovery. Stuck spins.

> > Hm. It was OK to use spinlocks to control buffer access when the max
> > delay was just the time to read or write one disk page. But it sounds
> > like we've pushed the code way past what it was designed to do. I think
> > this needs some careful thought, not just a quick hack like increasing
> > the timeout interval.
>
> After thinking more about this, simply increasing S_MAX_BUSY is clearly
> NOT a good answer. If you are under heavy load then processes that are
> spinning are making things worse, not better, because they are sucking
> CPU cycles that would be better spent on the processes that are holding
> the locks.

Our spinlocks don't go into an infinite test loop, right? They back off
and retest at random intervals.

I can't imagine we don't have similar btree lock needs other places in
the code were a solution already exists.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026