| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
| Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Btree runtime recovery. Stuck spins. |
| Date: | 2001-02-08 20:48:49 |
| Message-ID: | 12891.981665329@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> 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 explain why I tried to avoid spin stuck "detection" code
> in WAL? -:)
> 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dominic J. Eidson | 2001-02-08 20:52:14 | Re: Syslog and pg_options (for RPMs) |
| Previous Message | Lamar Owen | 2001-02-08 20:44:57 | Re: Syslog and pg_options (for RPMs) |