ERROR's turning FATAL in BRIN regression tests - Mailing list pgsql-hackers

Hi all,

I ran into a surprising behavior while hacking on the FSM delay patch.

I changed the signature of a freespace.c function that the BRIN code
calls, and this change by itself doesn't cause a crash. With the full
FSM patch, causing BRIN errors in manual queries in psql doesn't cause
a crash. However, during the BRIN regression tests, the queries that
purposely cause errors result in FATAL instead, causing a crash.

For example, brin_summarize_new_values() eventually leads to calling
index_open():

ereport(ERROR,
        (errcode(ERRCODE_WRONG_OBJECT_TYPE),
         errmsg("\"%s\" is not an index",
                        RelationGetRelationName(r))));


But the elevel is 21 (FATAL) in this partial stack trace:

#0  0x00005623aff8aed6 in proc_exit_prepare (code=1) at
/home/john/pgdev/postgresql/src/backend/storage/ipc/ipc.c:209
        __func__ = "proc_exit_prepare"
#1  0x00005623aff8adbb in proc_exit (code=1) at
/home/john/pgdev/postgresql/src/backend/storage/ipc/ipc.c:107
        __func__ = "proc_exit"
#2  0x00005623b01435c3 in errfinish (dummy=0) at
/home/john/pgdev/postgresql/src/backend/utils/error/elog.c:540
        edata = 0x5623b06f63c0 <errordata>
        elevel = 21
        oldcontext = 0x5623b2121b10
        econtext = 0x0
        __func__ = "errfinish"
#3  0x00005623afbb9ab1 in index_open (relationId=52389, lockmode=4) at
/home/john/pgdev/postgresql/src/backend/access/index/indexam.c:159
        __errno_location = <optimized out>
        r = 0x7f03773e1750
        __func__ = "index_open"


If I comment out the tests that purposely cause errors, the BRIN tests
fail normally, but then another test in the same parallel group
crashes, causing all later tests to fail.

--- 1 ----
! psql: FATAL:  the database system is in recovery mode

and

*** 65,67 ****
--- 65,74 ----
  -- Modify fillfactor in existing index
  alter index spgist_point_idx set (fillfactor = 90);
  reindex index spgist_point_idx;
+ WARNING:  terminating connection because of crash of another server process
+ DETAIL:  The postmaster has commanded this server process to roll
back the current transaction and exit, because another server process
exited abnormally and possibly corrupted shared memory.
+ HINT:  In a moment you should be able to reconnect to the database
and repeat your command.
+ server closed the connection unexpectedly
+     This probably means the server terminated abnormally
+     before or while processing the request.
+ connection to server was lost


I'm thoroughly stumped -- anyone have an idea where to look next?

Thanks,
-John Naylor