Re: pg_restore: [custom archiver] dumping a specific TOC data block out of order is not supported without ID on this input stream (fseek required)
От | Alban Hertroys |
---|---|
Тема | Re: pg_restore: [custom archiver] dumping a specific TOC data block out of order is not supported without ID on this input stream (fseek required) |
Дата | |
Msg-id | 009AA804-87CB-4204-AED0-8A3F2F489021@solfertje.student.utwente.nl обсуждение исходный текст |
Ответ на | Re: pg_restore: [custom archiver] dumping a specific TOC data block out of order is not supported without ID on this input stream (fseek required) (Glyn Astill <glynastill@yahoo.co.uk>) |
Ответы |
Re: pg_restore: [custom archiver] dumping a specific TOC data block out of order is not supported without ID on this input stream (fseek required)
|
Список | pgsql-general |
On 21 May 2010, at 11:58, Glyn Astill wrote: > Well I've ony just gotten round to taking another look at this, response inline below: > > --- On Fri, 30/4/10, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Glyn Astill <glynastill@yahoo.co.uk> >> writes: >>> The schema is fairly large, but I will try. >> >> My guess is that you can reproduce it with not a lot of >> data, if you can >> isolate the trigger condition. >> > > Hmm, tried reducing the amount of data and the issue goes away. Could this indicate some issue with the file, like an issuewith it's size (~~ 5gb)? Or could it be an issue with the data itself? The file-size in combination with an "out of order" error smells of a 32-bit integer wrap-around problem. And indeed, from the documentation (http://www.postgresql.org/docs/8.4/interactive/lo-intro.html): "One remaining advantage of the large object facility is that it allows values up to 2 GB in size" So I guess your large object is too large. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:737,4bf6617510414104348269!
В списке pgsql-general по дате отправления: