| 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
| 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 |