Re: Inherit regression outputs rows in alternative ordering when run on other table AM than heap - Mailing list pgsql-hackers

From Pavel Borisov
Subject Re: Inherit regression outputs rows in alternative ordering when run on other table AM than heap
Date
Msg-id CALT9ZEH00T0fSmep_nU6XczPA_h3-rJ1EEfY7hDdZjBiH87spg@mail.gmail.com
Whole thread
In response to Re: Inherit regression outputs rows in alternative ordering when run on other table AM than heap  (John Naylor <johncnaylorls@gmail.com>)
List pgsql-hackers
Hi, Jonh!

On Wed, 29 Apr 2026 at 11:49, John Naylor <johncnaylorls@gmail.com> wrote:
>
> On Fri, Mar 27, 2026 at 7:54 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
> > Existing inherit regression test results are tied to the particular
> > row order after UPDATE clause. The context is approximately the same
> > as in [1].
> >
> > When run on different table AM it shows the following difference in output:
>
> I think it'd be beneficial to make regression tests more reproducible
> across different table AMs. It's worth asking how much the ongoing
> maintenance cost would be, since I imagine the one you're testing is
> not the only one that shows differences.
>
I agree with you. However, it looks quite difficult for me to imagine
all possible tests differences that some (unspecified) custom AM's
could introduce to tests written in PG test suite (i.e. written
considering a single existing heap table AM). It might be beneficial
to use an iterative approach and fix what is cheap first.

At the same time, adapting PG tests to some known table access methods
looks like a too limited case to me.

So this thread only adds ORDER BY to tests that are inadvertently tied
to the heap rows order, and so are cheap enough to fix.
I tried to add ORDER BY's when they're beneficial in my opinion, not
too wide, and at the same time not limited just to test differences
for particular table AM.


Kind regards,
Pavel Borisov
Supabase



pgsql-hackers by date:

Previous
From: Ayush Tiwari
Date:
Subject: Re: [PATCH] Fix duplicate errmsg in ALTER TABLE SPLIT PARTITION
Next
From: shveta malik
Date:
Subject: Re: Parallel Apply