Btree runtime recovery. Stuck spins.

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

Responses

Browse pgsql-hackers by date

  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)