LLVM jit and matview

Hi,

I've found out an interesting problem that you can reproduce by running
installcheck against a database with enabled llvm jit (with and without the
patch I've sent in [1]):

# postgresql.conf
jit = on
jit_above_cost = 0
jit_optimize_above_cost = 0
jit_inline_above_cost = 0

# matview.sql
...
=# REFRESH MATERIALIZED VIEW CONCURRENTLY mvtest_tm;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

# gdb
Program received signal SIGSEGV, Segmentation fault.
0x00007f5fa2c24f80 in ?? ()
Traceback (most recent call last):
File "<string>", line 616, in lines
File "<string>", line 113, in run
gdb.error: No function contains program counter for selected frame.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "<string>", line 180, in <lambda>
File "<string>", line 191, in on_stop
File "<string>", line 222, in display
File "<string>", line 633, in lines
gdb.MemoryError: Cannot access memory at address 0x7f5fa2c24f80
>>> bt
#0 0x00007f5fa2c24f80 in ?? ()
#1 0x0000000000648218 in ShutdownExprContext
(econtext=econtext(at)entry=0x2988a20, isCommit=isCommit(at)entry=true) at
execUtils.c:851
#2 0x000000000064877e in FreeExprContext (econtext=0x2988a20,
isCommit=isCommit(at)entry=true) at execUtils.c:364
#3 0x00000000006487e0 in FreeExecutorState
(estate=estate(at)entry=0x2986bd8) at execUtils.c:202
#4 0x000000000063ed4e in standard_ExecutorEnd (queryDesc=0x3139100)
at execMain.c:514
#5 0x000000000063ed96 in ExecutorEnd
(queryDesc=queryDesc(at)entry=0x3139100) at execMain.c:466
#6 0x0000000000670c11 in _SPI_pquery
(queryDesc=queryDesc(at)entry=0x3139100,
fire_triggers=fire_triggers(at)entry=true, tcount=1) at spi.c:2455
#7 0x0000000000672d42 in _SPI_execute_plan
(plan=plan(at)entry=0x7ffef6c89b40, paramLI=paramLI(at)entry=0x0,
snapshot=snapshot(at)entry=0x0,
crosscheck_snapshot=crosscheck_snapshot(at)entry=0x0,
read_only=read_only(at)entry=false,
fire_triggers=fire_triggers(at)entry=true, tcount=1) at spi.c:2204
#8 0x00000000006730ba in SPI_execute (src=0x2c947f8 "SELECT newdata
FROM pg_temp_3.pg_temp_16397 newdata WHERE newdata IS NOT NULL AND
EXISTS (SELECT 1 FROM pg_temp_3.pg_temp_16397 newdata2 WHERE newdata2
IS NOT NULL AND newdata2 OPERATOR(pg_catalog.*=)"...,
read_only=read_only(at)entry=false, tcount=tcount(at)entry=1) at spi.c:418
#9 0x00000000005e52f2 in refresh_by_match_merge
(matviewOid=matviewOid(at)entry=16397, tempOid=tempOid(at)entry=16460,
relowner=relowner(at)entry=10, save_sec_context=0) at matview.c:632
#10 0x00000000005e619e in ExecRefreshMatView
(stmt=stmt(at)entry=0x1b83100, queryString=queryString(at)entry=0x1b82668
"REFRESH MATERIALIZED VIEW CONCURRENTLY mvtest_tm;",
params=params(at)entry=0x0,
completionTag=completionTag(at)entry=0x7ffef6c8a3c0 "") at matview.c:323
#11 0x00000000007a7926 in ProcessUtilitySlow
(pstate=pstate(at)entry=0x28a1d08, pstmt=pstmt(at)entry=0x1b831c0,
queryString=queryString(at)entry=0x1b82668 "REFRESH MATERIALIZED VIEW
CONCURRENTLY mvtest_tm;",
context=context(at)entry=PROCESS_UTILITY_TOPLEVEL,
params=params(at)entry=0x0, queryEnv=queryEnv(at)entry=0x0, dest=0x1b834b0,
completionTag=0x7ffef6c8a3c0 "") at utility.c:1493
#12 0x00000000007a69d5 in standard_ProcessUtility (pstmt=0x1b831c0,
queryString=0x1b82668 "REFRESH MATERIALIZED VIEW CONCURRENTLY
mvtest_tm;", context=PROCESS_UTILITY_TOPLEVEL, params=0x0,
queryEnv=0x0, dest=0x1b834b0, completionTag=0x7ffef6c8a3c0 "") at
utility.c:920
#13 0x00000000007a6a8d in ProcessUtility (pstmt=pstmt(at)entry=0x1b831c0,
queryString=<optimized out>, context=<optimized out>,
params=<optimized out>, queryEnv=<optimized out>,
dest=dest(at)entry=0x1b834b0, completionTag=0x7ffef6c8a3c0 "") at
utility.c:360
#14 0x00000000007a3162 in PortalRunUtility
(portal=portal(at)entry=0x1be6af8, pstmt=pstmt(at)entry=0x1b831c0,
isTopLevel=isTopLevel(at)entry=true,
setHoldSnapshot=setHoldSnapshot(at)entry=false,
dest=dest(at)entry=0x1b834b0,
completionTag=completionTag(at)entry=0x7ffef6c8a3c0 "") at pquery.c:1178
#15 0x00000000007a3cd6 in PortalRunMulti
(portal=portal(at)entry=0x1be6af8, isTopLevel=isTopLevel(at)entry=true,
setHoldSnapshot=setHoldSnapshot(at)entry=false,
dest=dest(at)entry=0x1b834b0, altdest=altdest(at)entry=0x1b834b0,
completionTag=completionTag(at)entry=0x7ffef6c8a3c0 "") at pquery.c:1324
#16 0x00000000007a4ac8 in PortalRun (portal=portal(at)entry=0x1be6af8,
count=count(at)entry=9223372036854775807,
isTopLevel=isTopLevel(at)entry=true, run_once=run_once(at)entry=true,
dest=dest(at)entry=0x1b834b0, altdest=altdest(at)entry=0x1b834b0,
completionTag=0x7ffef6c8a3c0 "") at pquery.c:799
#17 0x00000000007a0f3b in exec_simple_query
(query_string=query_string(at)entry=0x1b82668 "REFRESH MATERIALIZED VIEW
CONCURRENTLY mvtest_tm;") at postgres.c:1122
#18 0x00000000007a2c88 in PostgresMain (argc=<optimized out>,
argv=argv(at)entry=0x1bad178, dbname=0x1bacfe0 "ddolgov",
username=<optimized out>) at postgres.c:4153
#19 0x0000000000720378 in BackendRun (port=port(at)entry=0x1ba3980) at
postmaster.c:4361
#20 0x0000000000722f65 in BackendStartup (port=port(at)entry=0x1ba3980)
at postmaster.c:4033
#21 0x0000000000723245 in ServerLoop () at postmaster.c:1706
#22 0x00000000007244ca in PostmasterMain (argc=argc(at)entry=3,
argv=argv(at)entry=0x1b7d0f0) at postmaster.c:1379
#23 0x0000000000689e58 in main (argc=3, argv=0x1b7d0f0) at main.c:228

Interesting enough that without jit_optimize_above_cost everything is fine, so
I assume there is a problem in the optimized bitcode. So far I'm investigating
what exactly is wrong, but just visually disassembled version of bitcode with
and without optimization look indeed quite different.

[1]: https://www.postgresql.org/message-id/CA%2Bq6zcXZRZHVpWQeKoM%2BoG%2B6-ApPH9VnFLNTUrXS6Uk%2BKD2twg%40mail.gmail.com