Re: crash testing suggestions for 12 beta 1
От | Peter Geoghegan |
---|---|
Тема | Re: crash testing suggestions for 12 beta 1 |
Дата | |
Msg-id | CAH2-Wz=BLfTTKbvvAm0gN=M-Fw-9opyMwavkCSp8V4a3_1F6fg@mail.gmail.com обсуждение исходный текст |
Ответ на | crash testing suggestions for 12 beta 1 (Jeff Janes <jeff.janes@gmail.com>) |
Список | pgsql-hackers |
On Thu, May 23, 2019 at 8:24 AM Jeff Janes <jeff.janes@gmail.com> wrote: > Now that beta is out, I wanted to do some crash-recovery testing where I inject PANIC-inducing faults and see if it recoverscorrectly. Thank you for doing this. It's important work. > Making the ctid be tie-breakers in btree index is also tested inherently (plus I think Peter tested that pretty thoroughlyhimself with similar methods). As you may know, the B-Tree code has a tendency to soldier on when an index is corrupt. "Moving right" tends to conceal problems beyond concurrent page splits. I didn't do very much fault injection type testing with the B-Tree enhancements, but I did lean on amcheck heavily during development. Note that a new, extremely thorough option called "rootdescend" verification was added following the v12 work: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c1afd175b5b2e5c44f6da34988342e00ecdfb518 It probably wouldn't add noticeable overhead to use this during your testing, and maybe to combine it with the "heapallindexed" option, while using the bt_index_parent_check() variant -- that will detect almost any imaginable index corruption. Admittedly, amcheck didn't find any bugs in my code after the first couple of versions of the patch series, so this approach seems unlikely to find any problems now. Even still, it wouldn't be very difficult to do this extra step. It seems worthwhile to be thorough here, given that we depend on the B-Tree code so heavily. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: