Opened 9 months ago

Closed 4 months ago

#4386 closed defect (fixed)

[upgrade] ERROR: cannot drop function st_union(geometry) because other objects depend on it

Reported by: strk Owned by: komzpa
Priority: blocker Milestone: PostGIS 3.0.0
Component: build/upgrade/install Version: master
Keywords: Cc:

Description

Upgrades from 2.5 or in-dev are broken due to change in ST_Union signature.

See https://dronie.osgeo.org/postgis/postgis/241/3/2 which is building a PR adding ad-hoc testing for this case: https://git.osgeo.org/gitea/postgis/postgis/pulls/30

The signature of aggregate was changed by Komzpa to raise limit of 2G for usage: https://trac.osgeo.org/postgis/ticket/4340

Suggestions were provided to avoid this upgrade failure in the corresponding PR: https://github.com/postgis/postgis/pull/394

Change History (14)

comment:1 Changed 9 months ago by komzpa

Thanks for the testcase.

comment:2 Changed 9 months ago by strk

NOTE: #4352 would fix this case when running against PostgreSQL 12 or higher (just for the record, we still want to support older versions)

comment:3 Changed 8 months ago by komzpa

PR https://github.com/postgis/postgis/pull/403 (not passing tests currently)

comment:4 Changed 4 months ago by pramsey

What is the status here? I can upgrade from 2.5.

comment:5 Changed 4 months ago by pramsey

Resolution: wontfix
Status: assignedclosed

Not that this is a good thing, but we mostly have to just wait for the world to evolve to newer Pg versions that let us upgrade more transparently.

comment:6 Changed 4 months ago by strk

we mostly have to just wait for the world to evolve to newer Pg versions

My point is we could also be nice and while waiting for the world to evolve we could avoid changing names of things without a complelling reason....

It's just some cost/benefit math.

comment:7 Changed 4 months ago by dbaston

Yeah, the cost/benefit of this seems off. We break upgrade for users with ST_Union in a view, and in return we get ... possible union of inputs larger 1 gb, or not, depending on the geometry?

comment:8 Changed 4 months ago by pramsey

OK, how do we feel about waiting for a fix? Maybe a day or two to write it, and then lots of testing.

comment:9 Changed 4 months ago by pramsey

Untested, but in a working state for simple cases as far as I can tell, https://github.com/postgis/postgis/pull/489

comment:10 Changed 4 months ago by pramsey

Returned to old aggregate signature, but with new computation path for ST_Union(), other aggregates use the old path via geometry[]. Applied to trunk at r17856.

comment:11 Changed 4 months ago by Algunenano

Resolution: wontfix
Status: closedreopened

Multiple bots are complaining about this:

13:34:23 ERROR:  cannot drop function st_union(geometry) because other objects depend on it
13:34:23 DETAIL:  view upgrade_view_test depends on function st_union(geometry)

comment:12 Changed 4 months ago by pramsey

Yeah, this is #4523. It's not my fix here, it's the upgrade test PR from strk that I added along the way. It tests that ST_Union views are durable across upgrades, which I'm pretty sure they never were, because we always did drop/create on them. We only get away from that in Pg 12 which can do a create-or-replace. I'm commenting out strk's test.

comment:13 Changed 4 months ago by pramsey

In 17882:

Remove view testing from upgrade objects testing
References #4386

comment:14 Changed 4 months ago by pramsey

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.