Btree runtime recovery. Stuck spins. - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject Btree runtime recovery. Stuck spins.
Date
Msg-id 8F4C99C66D04D4118F580090272A7A234D32E3@sectorbase1.sectorbase.com
Whole thread Raw
Responses Re: Btree runtime recovery. Stuck spins.  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Syslog and pg_options (for RPMs)
Next
From: Lamar Owen
Date:
Subject: Re: Syslog and pg_options (for RPMs)