Re: Preferred way to submit a very large batch of bugs?

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Michael Malis <malis(at)pgrust(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Preferred way to submit a very large batch of bugs?
Date: 2026-11-04 16:48:24
Message-ID: autSKxwDyUUHwxuy@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
security(at)postgresql(dot)org 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2026-11-04 16:53:02 Re: Parallel vacuum: check XID wraparound failsafe between indexes
Previous Message Dmitry Dolgov 2026-11-04 16:04:21 Re: [PATCH] Refactor pgbench to make future improvements easier