Re: Gist Recovery testing

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Gist Recovery testing
Дата
Msg-id 23513.1118421992@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Gist Recovery testing  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: Gist Recovery testing  (Oleg Bartunov <oleg@sai.msu.su>)
Список pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes:
> Ok, I already realized WAL in GiST and tested with online backup. It works.
> Now I need test it on recovery after crash (power loss etc) and there is a 
> problem in GiST with incompleted inserts, I hope, I resolved it, but this 
> problem, I think, has the same nature as incompleted splits in btree code. For 
> solving, btree xlog code uses stack of incompleted splits and if they leaves 
> incompleted, btree_xlog_cleanup function completes them. I make use similar 
> idea, but I can't reproduce situation when xlog_cleanup makes some useful work 
> except just looks at void stack. So question: how is it possible to reproduce 
> desired behaviour?

It's not very easy; you have to arrange for the WAL history to end
between the two action records that you are interested in.  What I'd
suggest is- run test backend under GDB, set breakpoint between  making log entry for first split step and entry for
second.-let it reach the breakpoint- in another backend, commit some unrelated transaction to  force XLOG buffers to
disk-in GDB, "kill -9" to prevent test backend from proceeding
 

If you want to trace through the recovery as well, the best bet might be
to temporarily add a "sleep(30)" near the beginning of StartupXlog so
that you have time to reattach to the recovery process.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: User Quota Implementation
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Concrete proposal for large objects and MVCC