freenode
Databases & Infrastructure

PostgreSQL hackers brace for 1,000-plus AI-found bugs

A developer with a large private catalog of crashes, corruption, and MVCC flaws asks how to report them without drowning the project, and core contributors outline triage, security, and repro rules.

Michael Malis has told the PostgreSQL hackers list that custom tooling built over recent months has turned up more than 1,000 previously unreported bugs, spanning crashes, data corruption, and MVCC consistency failures. He prepared a searchable catalog by category and severity and asked for the least disruptive way to hand the findings over, noting the lists have already been hit by waves of automated reports.

Core developers answered with process, not a green light to dump everything at once. Álvaro Herrera said potential security problems (buffer overwrites or memory disclosure on the way down, not mere crashes) should go privately to security@postgresql.org, ideally just after a minor release so there is time to prepare fixes. Ordinary bugs belong in the project bug form, after categorization and prioritization so important work is not buried under trivial noise. Sample write-ups in a broad how-to question, he added, should not be treated as formal reports.

Andres Freund laid out sharper quality bars: cull duplicates that share a root cause, strip reproducers to the simplest form (preferring in-tree regression or isolation tests over sprawling scripts), and drop cases that only matter under absurd superuser abuse or convoluted queries unlikely to be actionable soon. Group related issues rather than filing a thousand separate reports. One of Malis’s examples, wrong results on a hot standby after a plain CREATE INDEX under default feedback settings, Freund called clearly worth fixing.

Others already deep in AI-assisted hunting described the same bottlenecks. Separating real security issues still needs careful human review because models both over- and under-classify. Public catalogs of unreviewed findings raise the risk of easier zero-days. Several suggested external tracking or review tooling so the mailing list and commitfest do not become the sole queue, while stressing hand reproduction, workload relevance, and root-cause fixes over symptom patches.

The exchange leaves the project with a clear short-term filter (security private, prioritize, minimize, group) and an open longer-term question of how its review machinery scales when automated discovery can outpace volunteer triage.