[postgis-tickets] [PostGIS] #4876: PostgreSQL 14 regress failure on uninstall

PostGIS trac at osgeo.org
Wed Mar 10 07:06:24 PST 2021


#4876: PostgreSQL 14 regress failure on uninstall
----------------------+---------------------------
  Reporter:  robe     |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  blocker  |  Milestone:  PostGIS 3.2.0
 Component:  postgis  |    Version:  master
Resolution:           |   Keywords:
----------------------+---------------------------

Comment (by robe):

 https://debbie.postgis.net/job/PG_Version_Dev_Git/7459/

 Looks like it started failing after these PostgreSQL master commits:


 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=fed10d4eec79242688382d03ddca82007160ee6f
 {{{
     Properly mark pg_stat_get_subscription() as returning a set. (details)
     Complain if a function-in-FROM returns a set when it shouldn't.
 (details)

 Commit fed10d4eec79242688382d03ddca82007160ee6f by tgl

 Properly mark pg_stat_get_subscription() as returning a set.

 The initial catalog data for this function failed to set proretset
 or provide a prorows estimate.  It accidentally worked anyway when
 invoked in the FROM clause, because the executor isn't too picky
 about this; but the planner didn't expect the function to return
 multiple rows, which could lead to bad plans.  Also the function
 would fail if invoked in the SELECT list.

 We can't easily back-patch this fix, but fortunately the bug's
 consequences aren't awful in most cases.  Getting this right is
 mainly an exercise in future-proofing.

 Discussion: https://postgr.es/m/1636062.1615141782@sss.pgh.pa.us

 The file was modified   src/include/catalog/catversion.h
 The file was modified   src/include/catalog/pg_proc.dat
 Commit d4545dc19b8ea670bf62e06d22b0e4e6fcb45153 by tgl

 Complain if a function-in-FROM returns a set when it shouldn't.

 Throw a "function protocol violation" error if a function in FROM
 tries to return a set though it wasn't marked proretset.  Although
 such cases work at the moment, it doesn't seem like something we
 want to guarantee will keep working.  Besides, there are other
 negative consequences of not setting the proretset flag, such as
 potentially bad plans.

 No back-patch, since if there is any third-party code violating
 this expectation, people wouldn't appreciate us breaking it in
 a minor release.

 Discussion: https://postgr.es/m/1636062.1615141782@sss.pgh.pa.us

 The file was modified   src/backend/executor/execSRF.c
 }}}


 and
 {{{

     Complain if a function-in-FROM returns a set when it shouldn't.
 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d4545dc19b8ea670bf62e06d22b0e4e6fcb45153


 }}}

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4876#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.


More information about the postgis-tickets mailing list