Re: how robust are custom dumps?
От | Magnus Hagander |
---|---|
Тема | Re: how robust are custom dumps? |
Дата | |
Msg-id | CABUevExDKSEp-QB5JgJqF3BKep2+jfGRat08ZossLCK7J8w5YQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: how robust are custom dumps? (Willy-Bas Loos <willybas@gmail.com>) |
Ответы |
Re: how robust are custom dumps?
|
Список | pgsql-general |
On Wed, Apr 25, 2012 at 09:42, Willy-Bas Loos <willybas@gmail.com> wrote: > On Tue, Apr 24, 2012 at 10:04 PM, Thom Brown <thom@linux.com> wrote: >> >> What was the experience? Is it possible you had specified a >> compression level without the format set to custom? That would result >> in a plain text output within a gzip file, which would then error out >> if you tried to restore it with pg_restore, but would be perfectly >> valid if you passed the uncompressed output directly into psql. > > > yes, probably. I remember that it was a binary file, but i didn't know about > the possibility of gzip in pg_dump. > Possibly the 2 GB size limit for a FAT partition was exceeded, but that > would have resulted in an error, so i would have known. We used to have a bug/lackoffeature in pg_dump at the 2GB boundary as well, IIRC, specifically on Win32. Maybe you were hit by that one.. > i think it's time to restore my trust in the custom dumps. :) Yes. > i do have one suggestion. > pg_restore only gives a user this feedback, when he makes this > mistake:"pg_restore: [archiver] input file does not appear to be a valid > archive". > > Would it be feasible for pg_restore to detect that it is a different pg_dump > format and inform the user about it? The main one you'd want to detect is plain I think - and I don't know if we can reliably detect that. It could be just a generic textfile, after all - how would we know the difference? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-general по дате отправления: