Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Sat, May 25, 2024 at 3:53 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> On Fri, May 24, 2024 at 11:00 PM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> >
> > 24.05.2024 22:29, Tom Lane wrote:
> > > The partition_split test has unstable results, as shown at [1].
> > > I suggest adding "ORDER BY conname" to the two queries shown
> > > to fail there. Better look at other queries in the test for
> > > possible similar problems, too.
> >
> > Yes, I've just reproduced it on an aarch64 device as follows:
> > echo "autovacuum_naptime = 1
> > autovacuum_vacuum_threshold = 1
> > autovacuum_analyze_threshold = 1
> > " > ~/temp.config
> > TEMP_CONFIG=~/temp.config TESTS="$(printf 'partition_split %.0s' `seq 100`)" make -s check-tests
> > ...
> > ok 80 - partition_split 749 ms
> > not ok 81 - partition_split 728 ms
> > ok 82 - partition_split 732 ms
> >
> > $ cat src/test/regress/regression.diffs
> > diff -U3 .../src/test/regress/expected/partition_split.out .../src/test/regress/results/partition_split.out
> > --- .../src/test/regress/expected/partition_split.out 2024-05-15 17:15:57.171999830 +0000
> > +++ .../src/test/regress/results/partition_split.out 2024-05-24 19:28:37.329999749 +0000
> > @@ -625,8 +625,8 @@
> > SELECT pg_get_constraintdef(oid), conname, conkey FROM pg_constraint WHERE conrelid =
> > 'sales_feb_mar_apr2022'::regclass::oid;
> > pg_get_constraintdef | conname | conkey
> > ---------------------------------------------------------------------+---------------------------------+--------
> > - CHECK ((sales_amount > 1)) | sales_range_sales_amount_check | {2}
> > FOREIGN KEY (salesperson_id) REFERENCES salespeople(salesperson_id) | sales_range_salesperson_id_fkey | {1}
> > + CHECK ((sales_amount > 1)) | sales_range_sales_amount_check | {2}
> > (2 rows)
> >
> > ALTER TABLE sales_range SPLIT PARTITION sales_feb_mar_apr2022 INTO
>
> Tom, Alexander, thank you for spotting this.
> I'm going to care about it later today.

ORDER BY is added in d53a4286d7 in these queries altogether with other
catalog queries with potentially unstable result.

------
Regards,
Alexander Korotkov
Supabase