Postgres, a lying disk, shrunk to its smallest set of lying flushes

What I ran

A Postgres finding was shrunk by running real worlds, each a restore from a snapshot, a power cut, a crash recovery and a read-back. The lying flushes were cut from 30 to 1, flush number 155, in 13 world runs.

What it shows

MIGHT. The application lost an acknowledged commit, seen once in the shrunk schedule of one lying flush, number 155, from a snapshot and then in 3 of 3 re-runs.

What it does not show

That exact replay of Postgres holds. It is not shown: the saved output lists exact replay of Postgres under what the gate does not claim, because Postgres's background writers and timers are not under control, so the commits acknowledged at the cut and the flush number a commit lands on move between runs.

Only lying flushes and the power cut were scheduled. No torn write, failed flush, network fault or kill was.

The cut was set at request 500, and only the lying flushes between the snapshot and the cut were candidates: 30 of them. The shrunk flush, number 155, is the last flush before the cut.

The lying flushes and the cut were set by the gate, so this is the shrink of a planted fault and is not a discovery.

According to the repository's source (src/campaign/ComposeShrink.fs), the product's shrinker, molina campaign --compose, takes an isolate and a stop and keeps the chance dials as they were drawn. This shrink was made by the gate's own code. No command reduces a lying-flush file or a window of virtual time on a customer's file, so a customer receives a smallest set of failures only where the shrinker can reduce the failure, and what it returns is the smallest it found against the runs made.

Conditions

The worlds were restored from a snapshot taken just before the failure, and the run is in screening mode.