MIME-Version: 1.0
References: 
 <CALT9ZEF8JA+h9+6r_cJFjR-us7KG=hWbM7GBC6SVrW3FpCDv8g@mail.gmail.com>
 <CANWCAZYBKjZndN69y0-1OWNfkD9wjJWpDUZTYe=G8phOnh1PMw@mail.gmail.com>
In-Reply-To: 
 <CANWCAZYBKjZndN69y0-1OWNfkD9wjJWpDUZTYe=G8phOnh1PMw@mail.gmail.com>
From: Pavel Borisov <pashkin.elfe@gmail.com>
Date: Wed, 29 Apr 2026 14:24:51 +0400
Message-ID: 
 <CALT9ZEH00T0fSmep_nU6XczPA_h3-rJ1EEfY7hDdZjBiH87spg@mail.gmail.com>
Subject: Re: Inherit regression outputs rows in alternative ordering when run
 on other table AM than heap
To: John Naylor <johncnaylorls@gmail.com>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CALT9ZEH00T0fSmep_nU6XczPA_h3-rJ1EEfY7hDdZjBiH87spg%40mail.gmail.com>
Precedence: bulk

Hi, Jonh!

On Wed, 29 Apr 2026 at 11:49, John Naylor <johncnaylorls@gmail.com> wrote:
>
> On Fri, Mar 27, 2026 at 7:54=E2=80=AFPM 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 out=
put:
>
> 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