Btree runtime recovery. Stuck spins.
От | Mikheev, Vadim |
---|---|
Тема | Btree runtime recovery. Stuck spins. |
Дата | |
Msg-id | 8F4C99C66D04D4118F580090272A7A234D32E3@sectorbase1.sectorbase.com обсуждение исходный текст |
Ответы |
Re: Btree runtime recovery. Stuck spins.
|
Список | 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 по дате отправления: