Thread: 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