Bug in pg_restore ... ?
I thought it was supposed to know "proper ordering" for doing the restore,
but:
%bin/pg_restore -d data ../db/data.dump | & tee data.data.log
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "resellers_id_seq" for "serial" column "resellers.id"
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "reseller_cookies_id_seq" for "serial" column "reseller_cookies.id"
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "transactions_id_seq" for "serial" column "transactions.id"
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "users_id_seq" for "serial" column "users.id"
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "user_cookies_id_seq" for "serial" column "user_cookies.id"
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "packages_id_seq" for "serial" column "packages.id"
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "billing_events_id_seq" for "serial" column "billing_events.id"
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "data_id_seq" for "serial" column "blogs.id"
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "groups_id_seq" for "serial" column "groups.id"
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "categories_id_seq" for "serial" column "categories.id"
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "articles_id_seq" for "serial" column "articles.id"
pg_restore: [archiver (db)] could not execute query: ERROR: type "tsvector" does not exist
tsvector is defined in the dump, but appears to be *after* the TABLES
themselves are created ... basically, shouldn't functions be created
before TABLES are?
This is with pg_restore from 7.4.6 ... so this might be something that has
been fixed already ... but figured I'd make sure it wasn't just me doing
something wrong ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
This is with pg_restore from 7.4.6 ... so this might be something that
has been fixed already ... but figured I'd make sure it wasn't just me
doing something wrong ...
Yes that bug definately exists in 7.4 we have had multiple problems with
it. I do believe it is fixed in the 8 series though.
J
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Thu, 9 Jun 2005, Joshua D. Drake wrote:
This is with pg_restore from 7.4.6 ... so this might be something that has
been fixed already ... but figured I'd make sure it wasn't just me doing
something wrong ...Yes that bug definately exists in 7.4 we have had multiple problems with it.
I do believe it is fixed in the 8 series though.
'k, is the bug with pg_dump, or pg_restore? I'm guessing pg_dump, but
just want to make sure ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Yes that bug definately exists in 7.4 we have had multiple problems
with it. I do believe it is fixed in the 8 series though.'k, is the bug with pg_dump, or pg_restore? I'm guessing pg_dump, but
just want to make sure ...
Yeah it is an ordering problem with pg_dump...
Sincerely,
Joshua D. Drake
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
"Joshua D. Drake" <jd@commandprompt.com> writes:
Yeah it is an ordering problem with pg_dump...
If you are using pg_restore you can hack around the problem by using
pg_restore's load-order-control switch (which was invented exactly to
let people work around pg_dump's problems ;-)). In this case though,
the simplest answer is probably to install tsearch2 into the new
database before you run pg_restore. It'll complain that the functions
already exist, but you can ignore that.
regards, tom lane
'k, is the bug with pg_dump, or pg_restore? I'm guessing pg_dump, but
just want to make sure ...Yeah it is an ordering problem with pg_dump...
The bug is in pg_dump and isn't fixed until 8.0.
Chris
On Thu, 9 Jun 2005, Tom Lane wrote:
"Joshua D. Drake" <jd@commandprompt.com> writes:
Yeah it is an ordering problem with pg_dump...
If you are using pg_restore you can hack around the problem by using
pg_restore's load-order-control switch (which was invented exactly to
let people work around pg_dump's problems ;-)). In this case though,
the simplest answer is probably to install tsearch2 into the new
database before you run pg_restore. It'll complain that the functions
already exist, but you can ignore that.
More then just that ... it errors out trying to create tables that already
exist from loading tsearch2.sql:
pg_restore: [archiver (db)] could not execute query: ERROR: relation "pg_ts_dict" already exists
So that doesn't appear to be an option either ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664