geog_brin_inclusion upgrade issue

[lr at pcorp.us]

> On Mon, Mar 17, 2025 at 12:20:35AM -0400, lr at pcorp.us wrote:
> > Well I think it's something broken, but worried that yours is not an
isolated
> situation.
> > So is the database that is failing the one that had missing bits of
> > geography
> 
> Yes -- the DB which hit an upgrade problem is the one where your queries
> seemed to show missing geo bits.
> 
> > Or is this in all your broken databases.  I wasn't sure if it was one
> > or just this particular one.
> 
> We only have only one instance that hit an issue running
> postgis_extensions_upgrade().
> 
> I looked across our ~35 instances and for *most* customers, your first
query
> returned 4 rows:
> 
> However for 3 customers only returned three:
> 
> a.client.telsasoft | CHANGED | rc=0 >>
>             family            | tl_typname | tr_typname |       oprcode
| amopmethod
> | amopsortfamily
>
------------------------------+------------+------------+-------------------
---+------------
> +----------------
>  brin_geography_inclusion_ops | gidx       | gidx       |
public.overlaps_geog |
> 3580 |              0
>  brin_geography_inclusion_ops | gidx       | geography  |
public.overlaps_geog
> |       3580 |              0
>  brin_geography_inclusion_ops | geography  | gidx       |
public.overlaps_geog
> |       3580 |              0
> (3 rows)

These 3 customers did not fail upgrade?  They upgraded without issue?

> And for the 2nd query, none of our instances returned anything at all,
except
> for customer "a", which gives one row:
> 

That's expected because the ids are different for each database.
So the only one that would return values would be the one that has those ids
for unique key violation.

So those other ones that only return 3 rows had no upgrade issue?
Was that after running the extra fix or without running fix at all?