Re: pg_restore TODO - delay PK creation
| От | Bruce Momjian |
|---|---|
| Тема | Re: pg_restore TODO - delay PK creation |
| Дата | |
| Msg-id | 200411010325.iA13POs27781@candle.pha.pa.us обсуждение исходный текст |
| Ответ на | Re: pg_restore TODO - delay PK creation ("Iain" <iain@mst.co.jp>) |
| Список | pgsql-admin |
Iain wrote: > Hi Bruce, > > OK, I've just looked into it and you are right, thanks. > > In the case I just tested I restored a 7.1 dump to a 7.4.6 db. I had assumed > that this is a restore time issue but in fact it is dependent on the format > of the dump file. I noticed the problem after the data load failed and I > checked the description of the table in question, it had a primary key. > > Worth noting for anybody preparing to upgrade large databases from old > versions. This db takes 8 hours to restore on 7.1 but I just dumped it and > restored it in less than 20 minutes total on 7.4 :) Quite a dramatic improvement, though 7.1 is in the ancient category. > I havn't used 7.4 for dumping/restoring for a long time so I had forgotten > how it worked. We're just starting a redevelopment that will include an > upgrade of the production db so I'm looking forward to working with 7.4 > again, though I'd like to be working on v8. > > Out of interest, what is the word on using newer versions of pg_dump on > older verisons of the DB - is it is possible or even wise to unload a 7.1 > DB with the 7.4 version of pg? It should work. I see version checks for >=70100 in the code so you should be fine using 7.4 or 8.0 pg_dump for 7.1. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-admin по дате отправления: