From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Vadim Mikheev <vmikheev(at)sectorbase(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Btree runtime recovery. Stuck spins. |
Date: | 2001-02-09 18:23:35 |
Message-ID: | 20532.981743015@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> 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.) The point though is that the code is tuned for use with
spinlocks protecting shared-memory data structures, where no one is
supposed to be holding the lock for long; so a short retry delay is
appropriate, and we don't need a very long time before declaring "stuck
spinlock" either. This is not optimal for cases where someone may be
holding the lock for a good while, but detuning the code so that it
works less well for the shmem-structure case isn't the answer.
We need two different mechanisms.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Denis Perchine | 2001-02-09 18:41:46 | Re: [HACKERS] Open 7.1 items |
Previous Message | Bruce Momjian | 2001-02-09 18:15:39 | Re: Open 7.1 items |