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 <[EMAIL PROTECTED]>
> Director of Information Systems, Support Center of Washington
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
