> > 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
Actually, btree split requires 3 simult. buffers locks and after that
_bt_getstackbuf may read *many* parent buffers while holding locks on
2 buffer
On Fri, Feb 09, 2001 at 01:23:35PM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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 di
Bruce Momjian <[EMAIL PROTECTED]> 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
anythin
> > 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 increasi
I wrote:
> "Vadim Mikheev" <[EMAIL PROTECTED]> writes:
>> 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
"Vadim Mikheev" <[EMAIL PROTECTED]> 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
> > 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
> processo
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> 2. During tests I've got stuck spin aborts couple of times.
> So I've increased S_MAX_BUSY, placed elog(NOTICE, "WOULD BE STUCK")
> for spins == 20001 in s_lock_sleep() and rerun tests.
> I've got *many* "WOULD BE STUCK" notices but no one abort.
> Do
Hi
1. Subj is implemented and is ON by default in current.
There is flag - fixbtree - to turn this feature OFF.
I've run some tests: 100 clients inserted big tuples (1700-1800
bytes) into single table with index. After splitting root page
elog(ERROR) was forced, as well as after each ~ 5th non-ro
