Re: Btree runtime recovery. Stuck spins.

"Vadim Mikheev" <vmikheev(at)sectorbase(dot)com> writes:
> Shouldn't we increase S_MAX_BUSY and use ERROR instead of FATAL?
>>
>> No. If you have delays exceeding a minute, or that are even a visible
>> fraction of a minute, then a spinlock is NOT the correct mechanism to be
>> using to wait ... because guess what, it's spinning, and consuming
>> processor time to no purpose. You should be using a lock instead for
>> anything that involves more than a trivial amount of delay.

> "Amount of delay" depends on system load - something we can't control...

> Btree uses spins to lock buffers (as all other access methods) and so
> I could use only spins in new code. And though tree recovery locks buffers
> for longer time than normal insert operations it's possible to get
> "stuck" spins when using concurrent buffers locks *everywhere* under
> heavy load (especially with WAL which requires holding buffer locks
> for duration of logging).

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.

regards, tom lane