Hello
I just migrated our databases from PostgreSQL version 9.6 to version 11.1. We got a segmentation fault while running this query:
SELECT f_2110 as x FROM baseline_denull
ORDER BY eid ASC
limit 500
OFFSET 131000;
It works in version 11,1 if offset + limit < 131000 approx (it is some number around it).
It works too if I disable jit (it was enabled). So this works:
set jit = 0;
SELECT f_2110 as x FROM baseline_denull
ORDER BY eid ASC
limit 500
OFFSET 131000;
It works all the time in version 9.6
The workaround seems to disable JIT. Is this a configuration problem or a bug?
We are using a compiled version of Postgres because we have tables (like this one) with thousands of columns.
This server was compiled as follows:
In Ubuntu 16.04:
sudo apt update
sudo apt install --yes libcrypto++-utils libssl-dev libcrypto++-dev libsystemd-dev libpthread-stubs0-dev libpthread-workqueue-dev
sudo apt install --yes docbook-xml docbook-xsl fop libxml2-utils xsltproc
sudo apt install --yes gcc zlib1g-dev libreadline6-dev make
sudo apt install --yes llvm-6.0 clang-6.0
sudo apt install --yes build-essential
sudo apt install --yes opensp
sudo locale-gen en_US.UTF-8
sudo apt install --yes libcrypto++-utils libssl-dev libcrypto++-dev libsystemd-dev libpthread-stubs0-dev libpthread-workqueue-dev
sudo apt install --yes docbook-xml docbook-xsl fop libxml2-utils xsltproc
sudo apt install --yes gcc zlib1g-dev libreadline6-dev make
sudo apt install --yes llvm-6.0 clang-6.0
sudo apt install --yes build-essential
sudo apt install --yes opensp
sudo locale-gen en_US.UTF-8
Download the source code:
mkdir -p ~/soft
cd ~/soft
wget https://ftp.postgresql.org/pub/source/v11.1/postgresql-11.1.tar.gz
tar xvzf postgresql-11.1.tar.gz
cd postgresql-11.1/
cd ~/soft
wget https://ftp.postgresql.org/pub/source/v11.1/postgresql-11.1.tar.gz
tar xvzf postgresql-11.1.tar.gz
cd postgresql-11.1/
./configure --prefix=$HOME/soft/postgresql/postgresql-11 --with-extra-version=ps.2.0 --with-llvm --with-openssl --with-systemd --with-blocksize=32 --with-wal-blocksize=32 --with-system-tzdata=/usr/share/zoneinfo
make world
make check # 11 tests fail. I assumed it is because the planner behaves differently because the change of blocksize.
make check # 11 tests fail. I assumed it is because the planner behaves differently because the change of blocksize.
make install-world
$HOME/soft/postgresql/postgresql-11/bin/initdb -D $HOME/soft/postgresql/postgresql-11/data/
Changes in ./data/postgresql.conf:
listen_addresses = '*'
max_connections = 300
work_mem = 32MB
maintenance_work_mem = 256MB
shared_buffers = 1024MB
log_timezone = 'US/Pacific'
log_destination = 'csvlog'
logging_collector = on
log_filename = 'postgresql-%Y-%m-%d.log'
log_rotation_size = 0
log_min_duration_statement = 1000
debug_print_parse = off
debug_print_rewritten = off
debug_print_plan = off
log_temp_files = 100000000
max_connections = 300
work_mem = 32MB
maintenance_work_mem = 256MB
shared_buffers = 1024MB
log_timezone = 'US/Pacific'
log_destination = 'csvlog'
logging_collector = on
log_filename = 'postgresql-%Y-%m-%d.log'
log_rotation_size = 0
log_min_duration_statement = 1000
debug_print_parse = off
debug_print_rewritten = off
debug_print_plan = off
log_temp_files = 100000000
jit = on # As a workaround, I turned off... but I want it on.
The database is created as:
CREATE DATABASE xxx
WITH
OWNER = user
ENCODING = 'UTF8'
LC_COLLATE = 'en_US.UTF-8'
LC_CTYPE = 'en_US.UTF-8'
TABLESPACE = pg_default
CONNECTION LIMIT = -1;
WITH
OWNER = user
ENCODING = 'UTF8'
LC_COLLATE = 'en_US.UTF-8'
LC_CTYPE = 'en_US.UTF-8'
TABLESPACE = pg_default
CONNECTION LIMIT = -1;
the table baseline_denull has 1765 columns, mainly numbers, like:
CREATE TABLE public.baseline_denull
(
eid integer,
f_19 integer,
f_21 integer,
f_23 integer,
f_31 integer,
f_34 integer,
f_35 integer,
f_42 text COLLATE pg_catalog."default",
f_43 text COLLATE pg_catalog."default",
f_45 text COLLATE pg_catalog."default",
f_46 integer,
f_47 integer,
f_48 double precision,
f_49 double precision,
f_50 double precision,
f_51 double precision,
f_52 integer,
f_53 date,
f_54 integer,
f_68 integer,
f_74 integer,
f_77 double precision,
f_78 double precision,
f_84 integer[],
f_87 integer[],
f_92 integer[],
f_93 integer[],
f_94 integer[],
f_95 integer[],
f_96 integer[],
f_102 integer[],
f_120 integer,
f_129 integer,
(
eid integer,
f_19 integer,
f_21 integer,
f_23 integer,
f_31 integer,
f_34 integer,
f_35 integer,
f_42 text COLLATE pg_catalog."default",
f_43 text COLLATE pg_catalog."default",
f_45 text COLLATE pg_catalog."default",
f_46 integer,
f_47 integer,
f_48 double precision,
f_49 double precision,
f_50 double precision,
f_51 double precision,
f_52 integer,
f_53 date,
f_54 integer,
f_68 integer,
f_74 integer,
f_77 double precision,
f_78 double precision,
f_84 integer[],
f_87 integer[],
f_92 integer[],
f_93 integer[],
f_94 integer[],
f_95 integer[],
f_96 integer[],
f_102 integer[],
f_120 integer,
f_129 integer,
etc
and 1 index:
CREATE INDEX baseline_denull_eid_idx
ON public.baseline_denull USING btree
(eid)
TABLESPACE pg_default;
ON public.baseline_denull USING btree
(eid)
TABLESPACE pg_default;
I have a core saved, It says:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: user xxx 172.17.0.64(36654) SELECT '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f3c0c08c290 in ?? ()
(gdb) bt
#0 0x00007f3c0c08c290 in ?? ()
#1 0x0000000000000000 in ?? ()
(gdb) quit
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: user xxx 172.17.0.64(36654) SELECT '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f3c0c08c290 in ?? ()
(gdb) bt
#0 0x00007f3c0c08c290 in ?? ()
#1 0x0000000000000000 in ?? ()
(gdb) quit
How could I enable JIT again without getting a segmentation fault?
Regards,
Pablo