[postgis-tickets] [PostGIS] #5564: BRIN indexes cause server crash after continuous autovacuum

[PostGIS]

#5564: BRIN indexes cause server crash after continuous autovacuum
----------------------+---------------------------
  Reporter:  robe     |      Owner:  pramsey
      Type:  defect   |     Status:  new
  Priority:  medium   |  Milestone:  PostGIS 3.5.0
 Component:  postgis  |    Version:  3.1.x
Resolution:           |   Keywords:
----------------------+---------------------------
Comment (by giubro):

 Hi,

 I may help here sine I originally worked on the introduction of BRINs in
 PostGIS, in 2016.

 The attached gdb back trace shows the source of the issue: the crash
 happens in this line

 https://github.com/postgres/postgres/blob/master/src/backend/access/brin/brin_inclusion.c#L522

 The same back trace shows what called the UNION support function above:
 it's the resummarization of the BRIN triggered by an autovacuum (here:
 https://github.com/postgres/postgres/blob/master/src/backend/access/brin/brin.c#L1542,
 line number does not perfectly match, but I recognize the called method).

 Looks like the problem here is the MERGE support function not properly
 defined for the OpClass in PostGIS.

 I guess in 2016 we never were able to trigger so often autovacuums (and
 so, many calls of the UNION support function during the resummarization)
 to reproduce this issue in our tests.

 The fix per se is not difficult: the MERGE support function takes only
 care of updating the bboxes of the merged geometries in the UNION, when
 the page summary is recalculated. This logic is already implemented in the
 ADD_VALUE method we defined ad-hoc in PostGIS.

 How to fix:

 1. Define a MERGE support function and add it in the OpClass
 2. Define a new UNION support function, as similarly done for the
 ADD_VALUE, that overrides the Postgresql core one in the OpClass (note
 that the MERGE support function is only used by ADD_VALUE and UNION)

 Solution 2. is maybe the most consistent with the current implementation
 in PostGIS due to the peculiarity of geospatial data type in order to be
 indexed (handling bboxes etc.), that originally brought us to redefine
 (and simplify, compared to Postgresql core version) the ADD_VALUE
 function. But I would like to hear about other opinions regarding this.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5564#comment:3>
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.