Hi!

When upgrading a server from version 6.5.2 to 7.0beta1, we hit the following
problems when reloading the data from pg_dumpall:

- Is it a "known feature" that when using "psql -f pgfull.dump" it aborts on
the "\connect" lines from pg_dumpall? The dump works fine if I start psql
and use \i to load it. (I reliase the documentation says use "psql <
filename", but I didn't read that far :-)

- It fails to reload datetime indexes, because of "DefineIndex: datetime_ops
class not found". I take it this is because of the new datetime stuff, but
it should at least be put into some notes somewhere that you have to tweak
the pg_dump output for these.

- It also failed to reload a view, but that was because the old pg_dump
dumped it as both a table and a view. Nothing wrong with 7.0 there.


Apart from these very minor issues, the reload went just fine. Just figured
that these small things should perhaps go into some notices somewhere.

//Magnus

Thu, 24 Feb 2000 15:53:08 +0100
Magnus Hagander <mha@sollentuna.net>
Minor problems reloading dump in 7.0beta1
On Thu, 24 Feb 2000, Magnus Hagander wrote:

> When upgrading a server from version 6.5.2 to 7.0beta1, we hit the following
> problems when reloading the data from pg_dumpall:
> 
> - Is it a "known feature" that when using "psql -f pgfull.dump" it aborts on
> the "\connect" lines from pg_dumpall?

No. It will abort if it cannot actually perform the connect, however ...

> The dump works fine if I start psql and use \i to load it. (I reliase
> the documentation says use "psql < filename", but I didn't read that
> far :-)

... makes this look like a really weird bug. What's the connect statement,
and what's the error message? (It better not abort without one. ;)


-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Thu, 24 Feb 2000 16:12:04 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Minor problems reloading dump in 7.0beta1
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi!
> 
> When upgrading a server from version 6.5.2 to 7.0beta1, we hit the following
> problems when reloading the data from pg_dumpall:
> 
> - Is it a "known feature" that when using "psql -f pgfull.dump" it aborts on
> the "\connect" lines from pg_dumpall? The dump works fine if I start psql
> and use \i to load it. (I reliase the documentation says use "psql <
> filename", but I didn't read that far :-)

This is a new psql feature that scripts exit on first failure, I think.

> - It fails to reload datetime indexes, because of "DefineIndex: datetime_ops
> class not found". I take it this is because of the new datetime stuff, but
> it should at least be put into some notes somewhere that you have to tweak
> the pg_dump output for these.

We need to fix that somehow.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 24 Feb 2000 10:18:35 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Minor problems reloading dump in 7.0beta1
Magnus Hagander <mha@sollentuna.net> writes:
> - It fails to reload datetime indexes, because of "DefineIndex: datetime_ops
> class not found".

Oops.  Comparing 6.5 and current pg_opclass contents, I see we are going
to have this trouble with timespan_ops and oid8_ops as well as with
datetime_ops (although very likely there are no user tables with indexes
on oid8?  Not certain though).

Bruce, do you want to hack the parser to drop these opclass names the
same way it's dropping network_ops?  Or do we need to adopt a cleaner
solution?

			regards, tom lane

Thu, 24 Feb 2000 11:05:59 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Minor problems reloading dump in 7.0beta1 
> Magnus Hagander <mha@sollentuna.net> writes:
> > - It fails to reload datetime indexes, because of "DefineIndex: datetime_ops
> > class not found".
> 
> Oops.  Comparing 6.5 and current pg_opclass contents, I see we are going
> to have this trouble with timespan_ops and oid8_ops as well as with
> datetime_ops (although very likely there are no user tables with indexes
> on oid8?  Not certain though).
> 
> Bruce, do you want to hack the parser to drop these opclass names the
> same way it's dropping network_ops?  Or do we need to adopt a cleaner
> solution?

Doing it now.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 24 Feb 2000 11:26:26 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Minor problems reloading dump in 7.0beta1
Applied.

> Magnus Hagander <mha@sollentuna.net> writes:
> > - It fails to reload datetime indexes, because of "DefineIndex: datetime_ops
> > class not found".
> 
> Oops.  Comparing 6.5 and current pg_opclass contents, I see we are going
> to have this trouble with timespan_ops and oid8_ops as well as with
> datetime_ops (although very likely there are no user tables with indexes
> on oid8?  Not certain though).
> 
> Bruce, do you want to hack the parser to drop these opclass names the
> same way it's dropping network_ops?  Or do we need to adopt a cleaner
> solution?
> 
> 			regards, tom lane
> 
> ************
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 24 Feb 2000 11:33:30 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] Minor problems reloading dump in 7.0beta1