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

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: ktr(at)goldin-rudahl(dot)com
Subject: BUG #17065: pg_restore never returns even on simple situations (maybe I just don't understand something)
Date: 2021-06-19 11:28:45
Message-ID: 17065-19b17b44a866cb35@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 17065
Logged by: kurt rudahl
Email address: ktr(at)goldin-rudahl(dot)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.

Responses

Browse pgsql-bugs by date

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