Hi, Tom! On Tue, 22 Apr 2025 at 21:13, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Pavel Borisov <pashkin.e...@gmail.com> writes: > > On Tue, 22 Apr 2025 at 20:22, Alexander Korotkov <aekorot...@gmail.com> > > wrote: > >> On Tue, Apr 22, 2025 at 7:20 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >>> Alexander Korotkov <aekorot...@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
v3-0001-Fortify-float4-and-float8-regression-tests-agains.patch
Description: Binary data
