Segfault when restoring -Fd dump on current HEAD

From: hubert depesz lubaczewski <depesz(at)depesz(dot)com>
To: pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org>
Subject: Segfault when restoring -Fd dump on current HEAD
Date: 2019-02-25 07:45:39
Message-ID: 20190225074539.az6j3u464cvsoxh6@depesz.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,
I did upgrade of my test pg. Part of this is pg_dump -Fd of each
database, then upgrade binaries, then initdb, and pg_restore.

But - I can't restore any database that has any data - I get segfaults.

For example, with gdb:

=$ gdb --args pg_restore -vvvvv -C -Fd backup-20190225074600.10361-db-depesz.dump
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from pg_restore...done.
(gdb) run
Starting program: /home/pgdba/work/bin/pg_restore -vvvvv -C -Fd backup-20190225074600.10361-db-depesz.dump
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
--
-- PostgreSQL database dump
--

-- Dumped from database version 12devel
-- Dumped by pg_dump version 12devel

-- Started on 2019-02-25 07:46:01 CET

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET client_min_messages = warning;
SET row_security = off;

pg_restore: creating DATABASE "depesz"
--
-- TOC entry 2148 (class 1262 OID 16631)
-- Name: depesz; Type: DATABASE; Schema: -; Owner: depesz
--

CREATE DATABASE depesz WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';

ALTER DATABASE depesz OWNER TO depesz;

pg_restore: connecting to new database "depesz"
\connect depesz

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET client_min_messages = warning;
SET row_security = off;

pg_restore: creating TABLE "public.test"
SET default_tablespace = '';

SET default_with_oids = false;

--
-- TOC entry 196 (class 1259 OID 16632)
-- Name: test; Type: TABLE; Schema: public; Owner: depesz
--

CREATE TABLE public.test (
i integer
);

ALTER TABLE public.test OWNER TO depesz;

--
-- TOC entry 2142 (class 0 OID 16632)
-- Dependencies: 196
-- Data for Name: test; Type: TABLE DATA; Schema: public; Owner: depesz
-- File: 2142.dat
--

Program received signal SIGSEGV, Segmentation fault.
0x000055555555d99c in _printTocEntry (AH=AH(at)entry=0x55555577e350, te=te(at)entry=0x5555557844a0, isData=isData(at)entry=true) at pg_backup_archiver.c:3636
3636 pg_backup_archiver.c: No such file or directory.
(gdb) bt
#0 0x000055555555d99c in _printTocEntry (AH=AH(at)entry=0x55555577e350, te=te(at)entry=0x5555557844a0, isData=isData(at)entry=true) at pg_backup_archiver.c:3636
#1 0x000055555555e41d in restore_toc_entry (AH=AH(at)entry=0x55555577e350, te=te(at)entry=0x5555557844a0, is_parallel=is_parallel(at)entry=false) at pg_backup_archiver.c:852
#2 0x000055555555eebb in RestoreArchive (AHX=0x55555577e350) at pg_backup_archiver.c:675
#3 0x000055555555aaab in main (argc=5, argv=<optimized out>) at pg_restore.c:432
(gdb)

if you'd need the dump to investigate - it's available here:
https://www.depesz.com/wp-content/uploads/2019/02/bad.dump.tar.gz

Unfortunately I don't have previous binaries, but I refreshed previously
around a week ago.

Best regards,

depesz

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2019-02-25 07:47:28 Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Previous Message Fabien COELHO 2019-02-25 07:43:16 Re: POC: converting Lists into arrays