Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?

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(at)scw(dot)org>
> > Director of Information Systems, Support Center of Washington
> >
> >
>
> Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org
>
>

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