Thread: BUG #17065: pg_restore never returns even on simple situations (maybe I just don't understand something)

The following bug has been logged on the website:

Bug reference:      17065
Logged by:          kurt rudahl
Email address:      ktr@goldin-rudahl.com
PostgreSQL version: 13.3
Operating system:   linux centos 7.5
Description:

Been using pg_dump for years but never needed pg_restore. I've read the docs
very carefully and cannot see where I'm failing.

To create a simple test case I created a new VM and installed
postgresql13.3

Then I created two DBs:
    createdb -l C -E UTF-8 original -T template0
    createdb -l C -E UTF-8 copy -T template0

I loaded 'original' with
cat testdb.sql
CREATE TABLE animals (
    who character(16),
    count integer,
    attribute character(32),
    animal character(32)
    );

INSERT into animals values('Mary',1,'little','lamb');
INSERT into animals values('Jane',7,'spotted','tua nuen, tua thong');
INSERT into animals values('Jean',100000,'green','pterodactyl');
INSERT into animals values('Joan',3,'hungry','lion');
INSERT into animals values('June',5,'mortgaged','toe');

I made two pg_dumps:
pg_dump -F c -Z 0 --inserts -E UTF8 -f animals-c
pg_dump -F p --inserts -E UTF8 -f animals-p

I examined the contents of animals-p. It contains about what I would
expect.

Then I stopped postgresql and tarred /var/lib/pgsql. I can send it if you
like.
I also shutdown the vm and tarred a copy of it.

Then I restarted the vm and restarted postgresql. I checked that db
'original' had what I expected.

I tried the following commands, as user postgres
-bash-4.2$ pg_restore -d copy 
^C
-bash-4.2$ pg_restore -d copy -v
^C
-bash-4.2$ pg_restore -f animals-c -l
^C
-bash-4.2$ pg_restore -f animals-p -l

In each case, I ctrl-C'd after about 10 minutes of no activity. I'm not sure
what behavior I should have seen for the first two of these although I would
have expected the 'copy' db to become loaded (which it wasn't). The
documentation tells me however that the two '-l' commands should have
produced a list of the (single) table contained in each of the dump files
(animals-c and animals-p).

System info: OS centos 7.5
postgresql 1.3.
uname -a: Linux centos7-64 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
1GB RAM

Since this was an installation from RPM's, presumably my c compiler,
libraries etc are not important

This is NOT specific to this postgres version. I can replicate this behavior
all the way back to version 9.0

I'm sure there's something really stupid that I'm not seeing, but at the
moment I have stopped trusting all the dump files I've accumulated and
carefully stored over the years. Your input gratefully appreciated.

PG Bug reporting form <noreply@postgresql.org> writes:
> I tried the following commands, as user postgres
> -bash-4.2$ pg_restore -d copy 
> ^C
> -bash-4.2$ pg_restore -d copy -v
> ^C
> -bash-4.2$ pg_restore -f animals-c -l
> ^C
> -bash-4.2$ pg_restore -f animals-p -l

> In each case, I ctrl-C'd after about 10 minutes of no activity.

In all these cases, pg_restore is expecting archive input to be
supplied on stdin.  You've provided switches that indicate where
its output ought to go, but there's no input.  Try something like

pg_restore -l animals-c

pg_restore -l <animals-c

pg_restore -d copy animals-c

pg_restore -f - animals-c

            regards, tom lane