Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1? - Mailing list pgsql-hackers

okay, not sure how we should document this, but apparently pg_dumpall
doesn't work as the man page at:

http://www.postgresql.org/users-lounge/docs/7.0/user/app-pgdumpall.htm

appears to suggest:

==========================
%pg_dumpall -h pgsql
psql: No pg_hba.conf entry for host localhost, user pgsql, database
template1
\connect template1
select datdba into table tmp_pg_shadow       from pg_database where
datname = 'template1';
delete from pg_shadow where usesysid <> tmp_pg_shadow.datdba;
drop table tmp_pg_shadow;
copy pg_shadow from stdin;
psql: No pg_hba.conf entry for host localhost, user pgsql, database
template1
\.
delete from pg_group;
copy pg_group from stdin;
psql: No pg_hba.conf entry for host localhost, user pgsql, database
template1
\.
psql: No pg_hba.conf entry for host localhost, user pgsql, database
template1
========================

Now, I swore I did a 'setenv PGHOST db.hub.org' to get around it, and it
still failed, but now its working ... most confusing :(

But, still, pg_dumpall doesn't appear to accept the -h option in v7.0.3
...

On Tue, 10 Apr 2001, The Hermit Hacker wrote:

>
> No errors, nothing ... here is the backend:
>
> %bin/postmaster -D /usr/local/pgsql/data
> DEBUG:  database system was shut down at 2001-04-10 15:04:08 ADT
> DEBUG:  CheckPoint record at (0, 1522068)
> DEBUG:  Redo record at (0, 1522068); Undo record at (0, 0); Shutdown TRUE
> DEBUG:  NextTransactionId: 615; NextOid: 18720
> DEBUG:  database system is in production state
> DEBUG:  copy: line 445, XLogWrite: new log file created - consider increasing WAL_FILES
> DEBUG:  XLogWrite: new log file created - consider increasing WAL_FILES
> DEBUG:  XLogWrite: new log file created - consider increasing WAL_FILES
> DEBUG:  MoveOfflineLogs: remove 0000000000000000
>
> and I ran the restore in 'script' to save everything, and as:
>
> psql -q template1 < pg_dumpall.out
>
> and there are no errors in the resultant file ...
>
> For all intensive purposes, the restore *looked* clean ... but, going back
> and looking at the dump file, the dump wasn't clean *puzzled look*
>
> I'm going to have to look at this some more, but its pg_dumpall in v7.0.3
> that is dumping the wrong data, not the restore :(
>
> all 77 databases got dump'd as the same database:
>
> You are now connected to database wind.
> wind=# \d
>                List of relations
>            Name           |   Type   |  Owner
> --------------------------+----------+---------
>  buy                      | table    | jeff
>  buy_bid_seq              | sequence | jeff
>  clients_c_id_seq         | sequence | jeff
>  cppvad_clients           | table    | jeff
>  cppvad_clients_cc_id_seq | sequence | jeff
>  cppvad_info              | table    | jeff
>  cppvad_info_cid_seq      | sequence | jeff
>  download                 | table    | jeff
>  download_dlid_seq        | sequence | jeff
>  exchange                 | table    | jeff
>  exchange_exid_seq        | sequence | jeff
>  gallery                  | table    | scrappy
>  listing                  | table    | area902
>  listing_lid_seq          | sequence | area902
>  ndict10                  | table    | pgsql
>  ndict11                  | table    | pgsql
>  ndict12                  | table    | pgsql
>  ndict16                  | table    | pgsql
>  ndict2                   | table    | pgsql
>  ndict3                   | table    | pgsql
>  ndict32                  | table    | pgsql
>  ndict4                   | table    | pgsql
>  ndict5                   | table    | pgsql
>  ndict6                   | table    | pgsql
>  ndict7                   | table    | pgsql
>  ndict8                   | table    | pgsql
>  ndict9                   | table    | pgsql
>  projects                 | table    | scrappy
>  thepress                 | table    | jeff
>  thepress_id_seq          | sequence | jeff
>  ticket                   | table    | pgsql
>  ticket_comments          | table    | pgsql
>  ticket_ticket_id_seq     | sequence | pgsql
>  ticket_times             | table    | pgsql
> (34 rows)
> wind=# \connect viper
> You are now connected to database viper.
> viper=# \d
>                List of relations
>            Name           |   Type   |  Owner
> --------------------------+----------+---------
>  buy                      | table    | jeff
>  buy_bid_seq              | sequence | jeff
>  clients_c_id_seq         | sequence | jeff
>  cppvad_clients           | table    | jeff
>  cppvad_clients_cc_id_seq | sequence | jeff
>  cppvad_info              | table    | jeff
>  cppvad_info_cid_seq      | sequence | jeff
>  download                 | table    | jeff
>  download_dlid_seq        | sequence | jeff
>  exchange                 | table    | jeff
>  exchange_exid_seq        | sequence | jeff
>  gallery                  | table    | scrappy
>  listing                  | table    | area902
>  listing_lid_seq          | sequence | area902
>  ndict10                  | table    | pgsql
>  ndict11                  | table    | pgsql
>  ndict12                  | table    | pgsql
>  ndict16                  | table    | pgsql
>  ndict2                   | table    | pgsql
>  ndict3                   | table    | pgsql
>  ndict32                  | table    | pgsql
>  ndict4                   | table    | pgsql
>  ndict5                   | table    | pgsql
>  ndict6                   | table    | pgsql
>  ndict7                   | table    | pgsql
>  ndict8                   | table    | pgsql
>  ndict9                   | table    | pgsql
>  projects                 | table    | scrappy
>  thepress                 | table    | jeff
>  thepress_id_seq          | sequence | jeff
>  ticket                   | table    | pgsql
>  ticket_comments          | table    | pgsql
>  ticket_ticket_id_seq     | sequence | pgsql
>  ticket_times             | table    | pgsql
> (34 rows)
>
>
> neat ...
>
>
> On Tue, 10 Apr 2001, Joel Burton wrote:
>
> > On Tue, 10 Apr 2001, The Hermit Hacker wrote:
> >
> > > all I did was use pg_dumpall from v7.0.3 to dump to a text file, and
> > > "psql template1 < dumpfile" to load it back in again ...
> > >
> > > obviously this doesn't work like it has in the past?
> >
> > Marc --
> >
> > Was there an error message during restore?
> >
> > I've been dumping/restoring w/7.1 since long before beta, w/o real
> > problems, but haven't been doing this w/7.0.3 stuff. But still, psql
> > should give you some error messages.
> >
> > (I'm sure you know this, but for the benefit of others on the list)
> > In Linux, I usually use the command)
> >
> >    psql dbname < dumpfile 2>&1 | grep ERROR
> >
> > so that I don't miss any errors among the all the NOTICEs
> >
> >
> > --
> > Joel Burton   <jburton@scw.org>
> > Director of Information Systems, Support Center of Washington
> >
> >
>
> Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org
>
>

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org