On Wed, May 13, 2020 at 4:32 PM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > I think my initial approach for this would be to use a fuzzing tool that > generates data blocks semi-randomly, then uses them as Postgres data > pages somehow, and see what happens -- examine any resulting crashes and > make individual judgement calls about the fix(es) necessary to prevent > each of them. I expect that many such pages would be rejected as > corrupt by page header checks.
As I mentioned in my response to Robert earlier, that's more or less been my experience with adversarial corruption generated using pg_hexedit. Within nbtree, as well as heapam. I put a lot of work into that tool, and have used it to simulate all kinds of weird scenarios. I've done things like corrupt individual tuple header fields, swap line pointers, create circular sibling links in indexes, corrupt varlena headers, and corrupt line pointer flags/status bits. Postgres itself rarely segfaults, and amcheck will only segfault with a truly contrived input. -- Peter Geoghegan
