Segmentation Fault

[mbwmbw1337]

[15796] LOG: server process (PID 150552) was terminated by signal 11: Segmentation fault
[15796] DETAIL: Failed process was running:
with recursive
pks_fks as (
-- pk + fk referencing col
select
contype::text as contype,
conname,
array_length(conkey, 1) as ncol,
conrelid as resorigtbl,
col as resorigcol,
ord
from pg_constraint
left join lateral unnest(conkey) with ordinality as _(col, ord) on true
where contype IN ('p', 'f')
union
-- fk referenced col
select
concat(contype, '_ref') as contype,
conname,
array_length(confkey, 1) as ncol,
confrelid,
col,
ord
from pg_constraint
left join lateral unnest(confkey) with ordinality as _(col, ord) on true
where contype='f'
),
views as (
select
c.oid as view_id,
n.nspname as view_schema,
c.relname as view_name,
r.ev_action as view_definition
from pg_class c
join pg_namespace n on n.oid = c.relnames

[mbwmbw1337]

Here is the core dump backtrace. Only happening when postgrest connects to the db.

(gdb) bt
#0  prepare_sort_from_pathkeys (root=0x55e7f4d335f0, lefttree=<optimized out>, pathkeys=0x55e7f4f1d1e0, relids=0x0, reqColIdx=0x0, adjust_tlist_in_place=<optimized out>, 
    p_numsortkeys=0x7ffedae3e6a4, p_sortColIdx=0x7ffedae3e6c0, p_sortOperators=0x7ffedae3e6b8, p_collations=0x7ffedae3e6b0, p_nullsFirst=0x7ffedae3e6a8)
    at optimizer/plan/./build/../src/backend/optimizer/plan/createplan.c:6178
#1  0x000055e7f396c5d4 in make_sort_from_pathkeys (root=root@entry=0x55e7f4d335f0, lefttree=<optimized out>, pathkeys=<optimized out>, relids=<optimized out>)
    at optimizer/plan/./build/../src/backend/optimizer/plan/createplan.c:6331
#2  0x000055e7f396d1fc in create_sort_plan (flags=4, best_path=0x55e7f4f20e80, root=0x55e7f4d335f0) at optimizer/plan/./build/../src/backend/optimizer/plan/createplan.c:2193
#3  create_plan_recurse (root=0x55e7f4d335f0, best_path=0x55e7f4f20e80, flags=4) at optimizer/plan/./build/../src/backend/optimizer/plan/createplan.c:491
#4  0x000055e7f396d565 in create_agg_plan (best_path=0x55e7f4f21050, root=0x55e7f4d335f0) at optimizer/plan/./build/../src/backend/optimizer/plan/createplan.c:2313
#5  create_plan_recurse (root=0x55e7f4d335f0, best_path=0x55e7f4f21050, flags=1) at optimizer/plan/./build/../src/backend/optimizer/plan/createplan.c:511
#6  0x000055e7f397013e in create_plan (root=0x55e7f4d335f0, best_path=<optimized out>) at optimizer/plan/./build/../src/backend/optimizer/plan/createplan.c:351
#7  0x000055e7f397c55f in standard_planner (parse=0x55e7f46bc030, query_string=<optimized out>, cursorOptions=2048, boundParams=<optimized out>)
    at optimizer/plan/./build/../src/backend/optimizer/plan/planner.c:433
#8  0x00007f7ad8d71e2a in pgss_planner (parse=0x55e7f46bc030, 
    query_string=0x55e7f5c6a028 "\n      with recursive\n      pks_fks as (\n        -- pk + fk referencing col\n        select\n          contype::text as contype,\n          conname,\n          array_length(conkey, 1) as ncol,\n          c"..., cursorOptions=2048, boundParams=0x55e7f4767778) at /home/builder/pgpro-stats-1.6.3/pgpro_stats.c:3280
#9  0x00007f7ad8d52b13 in pathman_planner_hook (parse=0x55e7f46bc030, 
    query_string=0x55e7f5c6a028 "\n      with recursive\n      pks_fks as (\n        -- pk + fk referencing col\n        select\n          contype::text as contype,\n          conname,\n          array_length(conkey, 1) as ncol,\n          c"..., cursorOptions=2048, boundParams=0x55e7f4767778) at ./build/../contrib/pg_pathman/src/hooks.c:763
#10 0x000055e7f397cabe in planner (parse=0x55e7f46bc030, 
    query_string=0x55e7f5c6a028 "\n      with recursive\n      pks_fks as (\n        -- pk + fk referencing col\n        select\n          contype::text as contype,\n          conname,\n          array_length(conkey, 1) as ncol,\n          c"..., cursorOptions=2048, boundParams=0x55e7f4767778) at optimizer/plan/./build/../src/backend/optimizer/plan/planner.c:285
#11 0x000055e7f3a5b428 in pg_plan_query (querytree=0x55e7f46bc030, 
    query_string=query_string@entry=0x55e7f5c6a028 "\n      with recursive\n      pks_fks as (\n        -- pk + fk referencing col\n        select\n          contype::text as contype,\n          conname,\n          array_length(conkey, 1) as ncol,\n          c"..., cursorOptions=cursorOptions@entry=2048, boundParams=boundParams@entry=0x55e7f4767778)
    at tcop/./build/../src/backend/tcop/postgres.c:911
#12 0x000055e7f3a5b51a in pg_plan_queries (querytrees=0x55e7f46bbfe8, 
    query_string=0x55e7f5c6a028 "\n      with recursive\n      pks_fks as (\n        -- pk + fk referencing col\n        select\n          contype::text as contype,\n          conname,\n          array_length(conkey, 1) as ncol,\n          c"..., cursorOptions=2048, boundParams=0x55e7f4767778) at tcop/./build/../src/backend/tcop/postgres.c:1003
#13 0x000055e7f3bc2f43 in BuildCachedPlan (plansource=plansource@entry=0x55e7f5c22240, qlist=0x55e7f46bbfe8, qlist@entry=0x0, boundParams=boundParams@entry=0x55e7f4767778, 
    queryEnv=queryEnv@entry=0x0) at utils/cache/./build/../src/backend/utils/cache/plancache.c:941
#14 0x000055e7f3bc326e in GetCachedPlan (plansource=0x55e7f5c22240, boundParams=0x55e7f4767778, owner=0x0, queryEnv=0x0) at utils/cache/./build/../src/backend/utils/cache/plancache.c:1225
#15 0x000055e7f3a60903 in exec_bind_message (input_message=0x7ffedae3f330) at tcop/./build/../src/backend/tcop/postgres.c:2018
#16 PostgresMain (dbname=<optimized out>, username=<optimized out>) at tcop/./build/../src/backend/tcop/postgres.c:4702
#17 0x000055e7f39ca73d in BackendRun (port=0x55e7f4759910, port=0x55e7f4759910) at postmaster/./build/../src/backend/postmaster/postmaster.c:4498
#18 BackendStartup (port=0x55e7f4759910) at postmaster/./build/../src/backend/postmaster/postmaster.c:4226
#19 ServerLoop () at postmaster/./build/../src/backend/postmaster/postmaster.c:1816
#20 0x000055e7f39c17a3 in PostmasterMain (argc=3, argv=<optimized out>) at postmaster/./build/../src/backend/postmaster/postmaster.c:1500
#21 0x000055e7f366bd5d in main (argc=3, argv=0x55e7f4627390) at main/./build/../src/backend/main/main.c:205

[develop7]

Have you considered filing a bug report against PostgreSQL? It kind of should not segfault on database connection, period. They could use a packet capture file too (Wireshark can do that).

You are welcome to post a link to the bug report here, I'd follow it closely and see what can we do on our side.

[steve-chavez]

@mbwmbw1337 What PostgreSQL version and PostgREST version are you using?

Really strange. As Andrei mentioned, this seems like a bug in PostgreSQL itself.

[wolfgangwalther]

Have you considered filing a bug report against PostgreSQL?

This had already happened a while back: https://www.postgresql.org/message-id/flat/CAGj%3D18FCNNBK2ChfxrUWbrUR8%3D2NKQKdUm3UQAJvCxTO089Qmg%40mail.gmail.com

This is certainly not a bug in PostgREST. PostgreSQL should not seg fault. The thread suggested that the stacktrace shows that this is not running on vanilla postgresql, but on the pgpro fork. So very likely a bug in pgpro.

[wolfgangwalther]

@mbwmbw1337 we now have a second report of this in #3185. I would like to understand the similarities between the two postgres configurations.

Which extensions are you using? Were you able to reproduce this without the pgpro fork you were using?