Обсуждение: BUG #17065: pg_restore never returns even on simple situations (maybe I just don't understand something)
BUG #17065: pg_restore never returns even on simple situations (maybe I just don't understand something)
От
PG Bug reporting form
Дата:
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