Re: [RFC] Property-based testing for Postgres

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Greg Burd <greg(at)burd(dot)me>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, postgres(at)jeltef(dot)nl, andrew(at)dunslane(dot)net
Subject: Re: [RFC] Property-based testing for Postgres
Date: 2026-11-03 16:28:31
Message-ID: 4956ea402b33b1e005e9062ea7999bae6c642504.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2026-11-03 at 14:34 +0000, Greg Burd wrote:
> > It seems much more valuable to test, say, data structure
> > invariants,
> > where we are likely to get creative with optimizations and might
> > break
> > something. Is this property testing system good for that?
>
> Yes, and that is one area where I think it earns its place.

For something in core, I think a few strong examples in this area would
be the best route.

>
> This style of testing fits AI well: the properties are easy for an
> agent to
> write, cheap to run, and the counterexample the engine shrinks to is
> exactly
> the artifact an agent can consume to produce a fix, a minimal input
> plus a
> seed that replays it.

AI can create tons of these tests, and that some percentage will find
bugs that others have missed, which is valuable. But carrying all those
tests in core doesn't sound very appealing to me.

Let's first look at the high-value testing areas and get feedback from
the people that work in those areas.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Manu 2026-11-03 16:58:54 PG19 regression in ecd9288624a: JSON_ARRAY() indexes that go stale
Previous Message Robert Haas 2026-11-03 16:17:57 Re: O(N^3) planning time in choose_plan_name() since 8c49a484e8e