From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | crash testing suggestions for 12 beta 1 |
Date: | 2019-05-23 15:24:12 |
Message-ID: | CAMkU=1y476DgDiqp5FGTZeq41T2xXQdrO25mbrjkxkPNFvVU_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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?
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2019-05-23 15:27:19 | Re: nitpick about poor style in MergeAttributes |
Previous Message | Fabien COELHO | 2019-05-23 15:23:14 | Re: refactoring - share str2*int64 functions |