Re: customizing pg_dump together with copy.c's DoCopy function
От | lynnsettle@yahoo.com |
---|---|
Тема | Re: customizing pg_dump together with copy.c's DoCopy function |
Дата | |
Msg-id | 1152632597.163801.222580@s13g2000cwa.googlegroups.com обсуждение исходный текст |
Ответ на | Re: customizing pg_dump together with copy.c's DoCopy function (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: customizing pg_dump together with copy.c's DoCopy function
|
Список | pgsql-general |
> > Is it possible to compile-link together frontend pg_dump code with > > backend code from copy.c? > > No. Why do you think you need to modify pg_dump at all? > pg_dump and pg_restore provide important advantages for upgrading a customer's database on site: They are fast. I want to minimize downtime. They allow compression. I often will have relatively little free disk space to work with. My concept is "customized dump", drop database, create new schema database, "customized restore". My upgrade requires many schema and data content changes. I've tried using standard SQL statements in perl scripts to do all of it, but even with no indexes on inserts, later creating indexes for the lookup work, and every other optimization I know of, a 100gb database requires several days to turn our old database into a new one. I was hoping that I could modify the speedy pg_dump/pg_restore utilities to make these changes "on the fly". It gets tricky because I have to restore some of the data to different tables having varying schema and also change the table linking. But this is all doable as long as I can "massage" the SQL statements and data both when it goes into the dump file and when it is getting restored back out. Or am I trying to do the impossible? -Lynn
В списке pgsql-general по дате отправления: