Re: [RFC] Property-based testing for Postgres

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

On Mon, 2026-11-02 at 21:28 +0000, Greg Burd wrote:
> I would rather present a small, sound, reproducible core and grow it
> from there if there is interest.
>
> So, is there appetite for a PBT framework in the tree on these terms?
> If
> this is a non-starter, that is useful to know now.  If it's worth
> pursuing, I'd like to hear from you.

Thank you for including a README, that's helpful.

Right now it's about 4KLOC, which seems reasonable for a new testing
approach, if it's useful.

I'd suggest that we try to control the scope here. Some of these seem
like property testing for the sake of property testing:

+/*
+ * sqrt bound: S = sqrt(abs(X)) is non-negative and, since numeric
sqrt rounds
+ * to a scale, S*S must not exceed abs(X) by more than a small
relative-plus-
+ * absolute tolerance. This is a sound one-sided bound: an exact sqrt
gives
+ * S*S = X, and the only slack is the rounding of the last digit, well
within
+ * abs(X) * 1e-10 + 1e-10. (The symmetric lower bound is scale-
dependent and
+ * fiddly to state soundly, so we assert only the clean upper side
plus the
+ * sign.)
+ */

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?

Also, how do you see this affecting the dev process? Do most people
need to be aware of this framework, adding new tests along with
features? Or would most of the value come from adding lots of new
property tests in a big batch, hoping to catch some longstanding bugs?

The timing of your proposal is not ideal, because AI is already finding
a lot of bugs, so finding more might be a thankless exercise until this
wave passes. So, if it doesn't get a lot of attention that may be the
reason why.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2026-11-02 22:49:05 Re: Fix BRIN numeric_minmax_multi_ops out of range value range merging
Previous Message Masahiko Sawada 2026-11-02 21:42:44 Re: First draft of PG 19 release notes