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

Hi,

On 2026-11-02 18:06:23 -0800, Michael Malis wrote:
> 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. I've included three
> of the bugs so you can get a sense of some of the findings.

> What's the least disruptive way for me to submit these issues? I've prepared a
> searchable catalog that makes it easy to browse through the bugs based on the
> category and severity of the issue, but I wanted to reach out first
> before sharing anything.

A few things that I think would be important:

- Make sure there aren't many duplicates. The same root cause can have many
different consequences. Of course you can't be expected to perfecly pinpoint
everything, but some effort is important.

- Minimize the heck out of reproducers. I think we have all grown extremely
tired of overcomplicated LLM generated repros. Ensure the simplest
implementation of a repro is chosen.
regression test > isolation test > tap test >>> random python/C/... script

- Make sure they're practically relevant. Make the server crash by doing
insane shit as superuser isn't interesting. Coming up with absurdly
convoluted query patterns that produce arguably kind of maybe inconsistent
results isn't likely actionable at the moment.

- Try to separate out security issues.

- Sending a thousand separate reports at once is likely just to overwhelm
everyone. Sending all of them at once is unlikely to be manageable. The
least bad idea I have is to group them into related issues and submit those
together.

- If some of the tooling for discovering these kind of issues could be morphed
into something that others can be used, or even better that can be made into
something the server detects, it could be helpful.

Going through the examples:

> ** Hot standby query gets wrong results from index built by plain
> CREATE INDEX **

This clearly is an issue we need to fix.

> Reproduction (primary with a streaming hot standby, default
> hot_standby_feedback = off and max_standby_streaming_delay = 30s or -1):

This is an example where including a minimal tap test might be helpful
(assuming this is done with LLM help), or even better an extension of one of
the existing tap tests. Thats easier to deal with than something requiring a
sequence of manual steps between multiple nodes.

> ** SQL-language function plan cache freezes parse-time literal coercions **

> In PostgreSQL 18 and later, non-inlined SQL-language functions cache
> their parse-analyzed Query tree across calls for the lifetime of the
> session. Because unknown-literal input conversion happens during parse
> analysis, parse-time literal coercions inside a SQL function body are
> frozen on the first call until a relation or function invalidation or a
> search_path change occurs. Consequently, INSERT ... VALUES ('now', ...)
> inside a SQL function writes the first call's transaction timestamp in
> all subsequent transactions, and literals whose parsing depends on GUC
> settings such as DateStyle or TimeZone retain the meaning from the
> first call after those GUCs change. In PostgreSQL 17 and earlier, a
> non-inlined SQL function body is re-parsed in every outer query, so
> 'now' evaluates to the current transaction's start time and GUC-
> dependent literals follow current settings, matching direct query
> execution. While the PL/pgSQL documentation (plpgsql.sgml, "Plan
> Caching") warns about this plan-caching behavior for 'now', SQL-language
> functions never had this behavior prior to 18 and neither the PostgreSQL
> 18 documentation nor the release notes state that SQL functions are
> affected.

Personally this seems like one that is at most worth reporting as a
documentation improvement. And given the flood we are facing, I'm not sure I'd
start with sending relatively minor stuff like this. As you say, this is
already present in a bunch of places.

> ** ON UPDATE CASCADE into narrower-typmod FK leaves orphans or re-points rows **
>
> When an ON UPDATE CASCADE foreign key references a primary key column
> with a wider typmod (for example, varchar(n) or char(n) referencing
> text, numeric(p,s) referencing numeric, or timestamp(p) referencing
> timestamp), the cascade query updates the referencing column through
> assignment coercion to the FK column's typmod. This coercion can alter
> the cascaded value without raising an error: varchar(n) and char(n)
> drop trailing blanks per the SQL length-coercion rule, and numeric(p,s)
> and timestamp(p) round. As a result, the FK row either keeps its old
> stored value so the FK re-check is skipped and an orphan row is
> committed, or receives a rounded value that matches a different PK row
> and silently re-points the reference. This violates the CREATE TABLE
> documentation for ON UPDATE CASCADE ("update the values of the
> referencing column(s) to the new values of the referenced column(s)")
> and breaks the invariant that a validated, enforced foreign key holds
> after every statement (a brute-force check and re-adding the constraint
> with ALTER TABLE ADD FOREIGN KEY both fail with SQLSTATE 23503).

To me this falls somewhere between "Don't do that, maybe it'd not hurt to warn
against" and "It'd be nice if we errored out" categories.

I'd again not start with this kind of thing, we have much bigger fish to fry,
and I don't think this is of huge practical relevance. But I could imagine
others disagreeing.

Greetings,

Andres Freund