BUG #17065: pg_restore never returns even on simple situations (maybe I just don't understand something) - Mailing list pgsql-bugs

From PG Bug reporting form
Subject BUG #17065: pg_restore never returns even on simple situations (maybe I just don't understand something)
Date
Msg-id 17065-19b17b44a866cb35@postgresql.org
Whole thread Raw
Responses Re: BUG #17065: pg_restore never returns even on simple situations (maybe I just don't understand something)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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.


pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17062: Assert failed in RemoveRoleFromObjectPolicy() on DROP OWNED policy applied to duplicate role
Next
From: Bernd Hopp
Date:
Subject: 'within group'- or percentile_cont-expression seems to have ramifications on table ordering