Re: pg_upgrade test for binary compatibility of core data types

On Sun, Nov 07, 2021 at 01:22:00PM -0600, Justin Pryzby wrote:
> That may be good enough for test.sh, but if the kludges were moved to a .sql
> script which was also run by the buildfarm (in stead of its hardcoded kludges), then
> it might be necessary to handle the additional stuff my patch did, like:

> [...]
>
> Or, maybe it's guaranteed that the animals all run latest version of old
> branches, in which case I think some of the BF's existing logic could be
> dropped, which would help to reconcile these two scripts:

I am pretty sure that it is safe to assume that all buildfarm animals
run the top of the stable branch they are testing, at least on the
community side. An advantage of moving all those SQLs to a script
that can be process with psql thanks to the \if metacommands you have
added is that buildfarm clients are not required to immediately update
their code to work properly. Considering as well that we should
minimize the amount of duplication between all those things, I'd like
to think that we'd better apply 0002 and consider a backpatch to allow
the buildfarm to catch up on it. It should at least allow to remove a
good chunk of the object cleanup done directly by the buildfarm.

>> This is for the basics in terms of fixing test.sh and what should be
>> backpatched. In this aspect patches 0001 and 0002 were a bit
>> incorrect. I am not sure that 0003 is that interesting as designed as
>> we would miss any new core types introduced.
>
> We wouldn't miss new core types, because of the 2nd part of type_sanity which
> tests that each core type was included in the "manytypes" table.

+-- XML might be disabled at compile-time
+AND oid != ALL(ARRAY['xml', 'gtsvector', 'pg_node_tree',
'pg_ndistinct', 'pg_dependencies', 'pg_mcv_list',
'pg_brin_bloom_summary', 'pg_brin_minmax_multi_summary']::regtype[])

I believe that this comment is incomplete, applying only to the first
element listed in this array. I guess that this had better document
why those catalogs are part of the list? Good to see that adding a
reg* in core would immediately be noticed though, as far as I
understand this SQL.
--
Michael