From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Btree runtime recovery. Stuck spins. |
Date: | 2001-02-08 20:03:42 |
Message-ID: | 8F4C99C66D04D4118F580090272A7A234D32E3@sectorbase1.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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-root page
split, so there was what to fix. After this I've run selects for
each key to check that index structure is correct.
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?
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Lamar Owen | 2001-02-08 20:44:57 | Re: Syslog and pg_options (for RPMs) |
Previous Message | Bruce Momjian | 2001-02-08 19:49:55 | Re: Syslog and pg_options (for RPMs) |