Re: pg_dump and large files - is this a problem?
От | Philip Warner |
---|---|
Тема | Re: pg_dump and large files - is this a problem? |
Дата | |
Msg-id | 5.1.0.14.0.20021019164409.04006380@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | pg_dump and large files - is this a problem? (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: pg_dump and large files - is this a problem?
Re: pg_dump and large files - is this a problem? |
Список | pgsql-hackers |
I have put the latest patch at: http://downloads.rhyme.com.au/postgresql/pg_dump/ along with two dump files of the regression DB, one with 4 byte and the other with 8 byte offsets. I can read/restore each from the other, so it looks pretty good. Once the endianness is tested, we should be OK. Known problems: - will not cope with > 4GB files and size_t not 64 bit. - when printing data position, it is assumed that off_t is UINT64 (we could remove this entirely - it's just for display) - if seek is not supported, then an intXX is assigned to off_t when file offsets are needed. This *should* not cause a problem since without seek, the offsets will not be written to the file. Changes from Prior Version: - No longer stores or outputs data length - Assumes result of ftello is correct if it disagrees with internally kept tally. - 'pg_restore -l' now shows sizes of int and offset. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
В списке pgsql-hackers по дате отправления: