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

From Vadim Mikheev
Subject Re: Btree runtime recovery. Stuck spins.
Date
Msg-id 005f01c09244$341e3440$4a79583f@sectorbase.com
Whole thread Raw
In response to Btree runtime recovery. Stuck spins.  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
Responses Re: Btree runtime recovery. Stuck spins.
List pgsql-hackers
> > 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).

So, probably we have to use some kind of light locks (without deadlock
detection) for buffers, in future.

Vadim




pgsql-hackers by date:

Previous
From: Justin Clift
Date:
Subject: SPI_exec - Trying to access SPI_tuptable - error of 'dereferencing pointer to incomplete type'
Next
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: Syslog and pg_options (for RPMs)