[postgis-tickets] [PostGIS] #5261: PostgreSQL 16 GUC changes breaks compile

[PostGIS]

#5261: PostgreSQL 16 GUC changes breaks compile
----------------------+---------------------------
  Reporter:  robe     |      Owner:  robe
      Type:  defect   |     Status:  new
  Priority:  blocker  |  Milestone:  PostGIS 3.4.0
 Component:  postgis  |    Version:  master
Resolution:           |   Keywords:  PG16
----------------------+---------------------------
Comment (by robe):

 Okay quite a few commits around gucs around 6 days ago.

 I suspect this one is the culprit

 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3057465acfbea2f3dd7a914a1478064022c6eecd


 {{{
 Replace the sorted array of GUC variables with a hash table.

 This gets rid of bsearch() in favor of hashed lookup.  The main
 advantage is that it becomes far cheaper to add new GUCs, since
 we needn't re-sort the pointer array.  Adding N new GUCs had
 been O(N^2 log N), but now it's closer to O(N).  We need to
 sort only in SHOW ALL and equivalent functions, which are
 hopefully not performance-critical to anybody.

 Also, merge GetNumConfigOptions() into get_guc_variables(),
 because in a world where the set of GUCs isn't fairly static
 you really want to consider those two results as tied together
 not independent.

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

 But might have also been changed later on:
 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=407b50f2d421bca5b134a0033176ea8f8c68dc6b


 {{{
 Store GUC data in a memory context, instead of using malloc().

 The only real argument for using malloc directly was that we needed
 the ability to not throw error on OOM; but mcxt.c grew that feature
 awhile ago.

 Keeping the data in a memory context improves accountability and
 debuggability --- for example, without this it's almost impossible
 to detect memory leaks in the GUC code with anything less costly
 than valgrind.  Moreover, the next patch in this series will add a
 hash table for GUC lookup, and it'd be pretty silly to be using
 palloc-dependent hash facilities alongside malloc'd storage of the
 underlying data.

 This is a bit invasive though, in particular causing an API break
 for GUC check hooks that want to modify the GUC's value or use an
 "extra" data structure.  They must now use guc_malloc() and
 guc_free() instead of malloc() and free().  Failure to change
 affected code will result in assertion failures or worse; but
 thanks to recent effort in the mcxt infrastructure, it shouldn't
 be too hard to diagnose such oversights (at least in assert-enabled
 builds).

 One note is that this changes ParseLongOption() to return short-lived
 palloc'd not malloc'd data.  There wasn't any caller for which the
 previous definition was better.

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


 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f13b2088fa2d4455936e65459b77698a4452f932


 {{{
 Add auxiliary lists to GUC data structures for better performance.

 The previous patch made addition of new GUCs cheap, but other GUC
 operations aren't improved and indeed get a bit slower, because
 hash_seq_search() is slower than just scanning a pointer array.

 However, most performance-critical GUC operations only need
 to touch a relatively small fraction of the GUCs; especially
 so for AtEOXact_GUC().  We can improve matters at the cost
 of a bit more space by adding dlist or slist links to the
 GUC data structures.  This patch invents lists that track

 (1) all GUCs with non-default "source";

 (2) all GUCs with nonempty state stack (implying they've
 been changed in the current transaction);

 (3) all GUCs due for reporting to the client.

 All of guc.c's performance-critical cases can make use of one or
 another of these lists to avoid searching the whole hash table.
 In particular, the stack list means that transaction end
 doesn't take time proportional to the number of GUCs, but
 only to the number changed in the current transaction.

 Discussion: https://postgr.es/m/2982579.1662416866@sss.pgh.pa.us
 }}}
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5261#comment:2>
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.