Segmentation fault caused by vacuum and analyze

[OneMoreSec]

Relevant system information:

• OS: CentOS 7
• PostgreSQL version: 11.2
• TimescaleDB version: 1.3.0
• Installation method: source

Describe the bug
A clear and concise description of what the bug is.
error log:
2019-05-09 10:56:50.714 UTC,,,23945,,5cd3f8f7.5d89,17,,2019-05-09 09:55:03 UTC,,0,LOG,00000,"server process (PID 7958) was terminated by signal 11: Segmentation fault","Failed proc
ess was running: ANALYZE t_mpp_1972_1d_pbpjwv_0 ",,,,,,,,""
2019-05-09 11:14:08.213 UTC,,,23945,,5cd3f8f7.5d89,22,,2019-05-09 09:55:03 UTC,,0,LOG,00000,"server process (PID 29776) was terminated by signal 11: Segmentation fault","Failed process was running: vacuum full t_mpp_2001_1d_a2gd6s_0 ",,,,,,,,""

coredump with gdb:
(gdb) bt
#0 process_vacuum (args=0x7ffcc08b5000) at /opt/software/timescaledb-1.3.0/src/process_utility.c:535
#1 process_ddl_command_start (args=0x7ffcc08b5000) at /opt/software/timescaledb-1.3.0/src/process_utility.c:2769
#2 timescaledb_ddl_command_start (pstmt=, query_string=, context=, params=, queryEnv=,
dest=, completion_tag=0x7ffcc08b5610 "") at /opt/software/timescaledb-1.3.0/src/process_utility.c:3024
#3 0x000000000073e046 in PortalRunUtility (portal=0x241a680, pstmt=0x2e361c0, isTopLevel=, setHoldSnapshot=, dest=0xcd7020 ,
completionTag=0x7ffcc08b5610 "") at pquery.c:1178
#4 0x000000000073ea87 in PortalRunMulti (portal=portal@entry=0x241a680, isTopLevel=isTopLevel@entry=true, setHoldSnapshot=setHoldSnapshot@entry=false,
dest=0xcd7020 , dest@entry=0x2345560, altdest=0xcd7020 , altdest@entry=0x2345560, completionTag=completionTag@entry=0x7ffcc08b5610 "")
at pquery.c:1331
#5 0x000000000073f5ec in PortalRun (portal=portal@entry=0x241a680, count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true, run_once=,
dest=dest@entry=0x2345560, altdest=altdest@entry=0x2345560, completionTag=completionTag@entry=0x7ffcc08b5610 "") at pquery.c:799
#6 0x000000000073d0fd in exec_execute_message (max_rows=9223372036854775807, portal_name=0x2345150 "") at postgres.c:2036
#7 PostgresMain (argc=, argv=argv@entry=0x23988b8, dbname=0x2398800 "ies_db", username=) at postgres.c:4245
#8 0x000000000048e61f in BackendRun (port=0x2396370) at postmaster.c:4361
#9 BackendStartup (port=0x2396370) at postmaster.c:4033
#10 ServerLoop () at postmaster.c:1706
#11 0x00000000006d3bfa in PostmasterMain (argc=argc@entry=3, argv=argv@entry=0x233fc50) at postmaster.c:1379
#12 0x000000000048f06f in main (argc=3, argv=0x233fc50) at main.c:228

(gdb) list
530 return false;
531
532 hcache = ts_hypertable_cache_pin();
533 foreach (lc, stmt->rels)
534 {
535 VacuumRelation *vacuum_rel = lfirst_node(VacuumRelation, lc);
536
537 hypertable_oid = ts_hypertable_relid(vacuum_rel->relation);
538 if (!OidIsValid(hypertable_oid))
539 continue;

To Reproduce
the defination of table which execute vacuum and analyze on is shown below, it's a hypertable created by "create_hypertable"

CREATE TABLE dw_ies.t_mpp_2000_1d_1gfjql_0
(
"time" timestamp with time zone NOT NULL,
entity_id text COLLATE pg_catalog."default" NOT NULL,
ind_065h4z9c4 numeric(25,5),
ind_04bd9kitu numeric(25,5),
ind_0kj1oo0n numeric(25,5),
ind_0d2fx4vjr numeric(25,5),
ind_053il36zt numeric(25,5),
ind_08fyru96n numeric(25,5),
ind_03waoydb numeric(25,5),
ind_08z31p9xh numeric(25,5),
ind_0d0o4bmve numeric(25,5),
ind_0c9cj0eoy numeric(25,5),
ind_03kojed4y numeric(25,5),
ind_0czsolqff numeric(25,5),
ind_0qago4lf numeric(25,5),
CONSTRAINT t_mpp_2000_1d_1gfjql_0_pkey PRIMARY KEY ("time", entity_id)
)
WITH (
OIDS = FALSE
)
TABLESPACE pg_default;
ALTER TABLE dw_ies.t_mpp_2000_1d_1gfjql_0
OWNER to dw_ies;
CREATE INDEX t_mpp_2000_1d_1gfjql_0_time_idx
ON dw_ies.t_mpp_2000_1d_1gfjql_0 USING btree
("time" DESC)
TABLESPACE pg_default;
CREATE TRIGGER ts_insert_blocker
BEFORE INSERT
ON dw_ies.t_mpp_2000_1d_1gfjql_0
FOR EACH ROW
EXECUTE PROCEDURE _timescaledb_internal.insert_blocker();

There are lots of hypertables in postgres, and we will execute VACUUM and ANALYZE on these tables regularly. The VACUUM task on some tables cause postgres crash.

[JLockerman]

@OneMoreSec could you share the exact command which causes the segfault? how consistently does it occur?

[OneMoreSec]

@JLockerman the exact command which causes the segfault is a simple "VACUUM FULL table_name" or "ANALYZE table_name" command.

[cevian]

Fixed by #1221