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 using
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
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
anything.)
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 discussion
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 buffers.
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
"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.
Does it
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
"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 what,
