Re: In-order pg_dump (or in-order COPY TO)
От | Adrian Klaver |
---|---|
Тема | Re: In-order pg_dump (or in-order COPY TO) |
Дата | |
Msg-id | d6390ed7-771d-4ebb-bea1-749883b25d00@aklaver.com обсуждение исходный текст |
Ответ на | Re: In-order pg_dump (or in-order COPY TO) (Dimitrios Apostolou <jimis@gmx.net>) |
Ответы |
Re: In-order pg_dump (or in-order COPY TO)
|
Список | pgsql-general |
On 8/31/25 10:52, Dimitrios Apostolou wrote: > When I first said "dump file without TOC" I actually meant "without offsets in the TOC". > > The fact that you get a TOC printed does not prove that the dump file includes a TOC with offsets. I did some digging in the code and see that the TOC is more then that, it stores a range of data. Still have not part where the offsets are ignored for writes to stdout, but will keep on digging. Getting back to your OP: "Unfortunately after I did pg_restore to a new server, I notice that the dumps from the new server are not being de-duplicated, all blocks are considered new." I ran a test on a much smaller database and I do not see the above. The commands and the Borg info for the archive are in attached file. > > All pg_dump -Fc commands that write to stdout, produce a file without offsets in the TOC. It has nothing to do with borg.ToC offsets must be filled in right before streaming each table, but this is impossible when the whole TOC has alreadybeen written to stdout in the beginning. > > Dimitris -- Adrian Klaver adrian.klaver@aklaver.com
Вложения
В списке pgsql-general по дате отправления: