Re: [GENERAL] Upgrading from 6.3->6.4.2/6.5b1 possible
От | Chris Bitmead |
---|---|
Тема | Re: [GENERAL] Upgrading from 6.3->6.4.2/6.5b1 possible |
Дата | |
Msg-id | 3751EFBA.4B3DE5D@bigfoot.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] Upgrading from 6.3->6.4.2/6.5b1 possible (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [GENERAL] Upgrading from 6.3->6.4.2/6.5b1 possible
|
Список | pgsql-general |
Bruce, I've put up a script for ftp that shows some wierd behaviour. This script was created by hand, so it's possible that some errors are caused by syntax errors (although I spent a while trying to find them without success). I think the point is that it is not recovering from/ reporting the error well (if there is one that is). It just gives errors about "max query size exceeded". Something happens part way through, and then you just get the same error thousands of times. ftp://tech.com.au/pub/load-error.gz Bruce Momjian wrote: > > > > > I've seen this problem too in 6.5 beta. I don't have a solution, but I'd > > just like to add my voice to say that this problem is real. > > > > Actually, I did have a kind of solution. If you dump proper insert > > statements into the dump and then run every insert in a separate > > process. Ugly but workable if the number isn't too great. > > > > while read A > > do > > echo "$A" | psql databasename > > done <dumpfilename > > > > > > We don't hear about this very often. Can someone tell us exactly what a > bad load looks like, or a cause. > > -- > Bruce Momjian | http://www.op.net/~candle > maillist@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
В списке pgsql-general по дате отправления: