Re: Fortify float4 and float8 regression tests by ordering test results
Pavel Borisov <pashkin.elfe@gmail.com>
From: Pavel Borisov <pashkin.elfe@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Korotkov <aekorotkov@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-04-22T17:28:53Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Avoid depending on post-UPDATE row order in float4/float8 tests.
- da83b1ea10c2 18.0 landed
Attachments
- v3-0001-Fortify-float4-and-float8-regression-tests-agains.patch (application/octet-stream) patch v3-0001
Hi, Tom! On Tue, 22 Apr 2025 at 21:13, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Pavel Borisov <pashkin.elfe@gmail.com> writes: > > On Tue, 22 Apr 2025 at 20:22, Alexander Korotkov <aekorotkov@gmail.com> wrote: > >> On Tue, Apr 22, 2025 at 7:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>> Alexander Korotkov <aekorotkov@gmail.com> writes: > >>>> I'd like to add that float4.out not only assumes that insert-ordering is > >>>> preserved (this could be more-or-less portable between table AMs). It also > >>>> assumes the way UPDATE moves updated rows. That seems quite > >>>> heap-specific. You can see in the following fragment, updated rows jump to > >>>> the bottom. > > >>> I'd be willing to consider a policy that we don't want to depend on > >>> exactly where UPDATE moves rows to. The proposed patch is not that, > >>> however. > > >> OK, that makes sense for me. > > > Thanks for this input! > > This was my first intention to fix only the test that was affected by > > UPDATE-order specifics, broke when runnung on an extension AM. > > Maybe I was too liberal and added ORDER BY's more than needed. > > I definitely agree to the proposal. > > On further reflection, this policy makes plenty of sense because even > heapam is not all that stable about row order after UPDATE. With > tables large enough to draw the attention of autovacuum, we've had > to use ORDER BY or other techniques to stabilize the results, because > the timing of background autovacuums affected where rows got put. > These tests are different only because the tables are small enough > and the updates few enough that autovacuum doesn't get involved. > I think it's reasonable that at a project-policy level we should > not consider that an excuse. For example, a change in autovacuum's > rules could probably break these tests even with heapam. > > On the other hand, as I mentioned earlier, a table AM that doesn't > reproduce original insertion order would break a whole lot more > tests than these. So that's a bridge I'd rather not cross, > at least not without a lot of consideration. > > BTW, you forgot to update expected/float4-misrounded-input.out. Added in v3. Thanks for a mention! Regards, Pavel Borisov