On 2026-Nov-02, Michael Malis wrote: > Hi all, > > I know the mailing lists have been hit with a flood of automated bug > reports lately and the last thing I want to do is create more > headaches for the team. Over the past few months, I've been building > a suite of tools for finding bugs. That work has surfaced over 1000 > previously unreported bugs ranging from crashes, to corruption, to > MVCC violations.
Hello Michael, As a first triage step, it's worth separating out the bugs that are potential security problems. Crashes per se aren't security bugs, but buffer overwrites or memory disclosure while the server is on its way down are likely security bugs. Those are better reported directly to [email protected] with no further public trail. (But if a minor release is close to be published, say in the following two weeks, it's not a bad idea to wait for that and see if it's going to be fixed there first; a bug reported too close to the deadline is unlikely to be dealt with in that release. Reporting immediately after the minors are out maximizes time to prepare fixes without zero-daying the project.) For non-security bugs, the preferred way is to get them submitted via the bug submission form [1]. Flooding the list with hundreds of bugs is unlikely to be welcome though, so I suppose you'll need to categorize/ prioritize so that we can get the important things out of the way without drowning in trivial issues. [1] https://www.postgresql.org/account/submitbug/ > I've included three of the bugs so you can get a sense of some of the > findings. Fun :-( (Please do not consider these as having been reported. We're unlikely to follow through based on these samples in your broader questions.) Thanks, -- Álvaro Herrera
