crash testing suggestions for 12 beta 1 - Mailing list pgsql-hackers

From Jeff Janes
Subject crash testing suggestions for 12 beta 1
Date
Msg-id CAMkU=1y476DgDiqp5FGTZeq41T2xXQdrO25mbrjkxkPNFvVU_g@mail.gmail.com
Whole thread Raw
Responses Re: crash testing suggestions for 12 beta 1  (Peter Geoghegan <pg@bowt.ie>)
Re: crash testing suggestions for 12 beta 1  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Now that beta is out, I wanted to do some crash-recovery testing where I inject PANIC-inducing faults and see if it recovers correctly. A long-lived Perl process keeps track of what it should find after the crash, and verifies that it finds it.  You will probably be familiar with the general theme from examples like the threads below.  Would anyone like to nominate some areas to focus on?  I think the pluggable storage refactoring work will be get inherently tested, so I'm not planning designing test specifically for that (unless there is a non-core plugin I should test with). Making the ctid be tie-breakers in btree index is also tested inherently (plus I think Peter tested that pretty thoroughly himself with similar methods).  I've already tested declarative partitioning where the tuples do a lot of migrating, and tested prepared transactions.  Any other suggestions for changes that might be risky and should be specifically targeted for testing? 



https://www.postgresql.org/message-id/CAMkU=1xEUuBphDwDmB1WjN4+td4kpnEniFaTBxnk1xzHCw8_OQ@mail.gmail.com  


Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: refactoring - share str2*int64 functions
Next
From: Mark Dilger
Date:
Subject: Re: nitpick about poor style in MergeAttributes