Re: In-order pg_dump (or in-order COPY TO)

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Dimitrios Apostolou <jimis(at)gmx(dot)net>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: In-order pg_dump (or in-order COPY TO)
Date: 2025-09-01 17:24:15
Message-ID: d6390ed7-771d-4ebb-bea1-749883b25d00@aklaver.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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 already been written to stdout in the beginning.
>
> Dimitris

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

Attachment Content-Type Size
pg_borg_test.txt text/plain 4.6 KB

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2025-09-01 17:54:16 Re: In-order pg_dump (or in-order COPY TO)
Previous Message Dimitrios Apostolou 2025-08-31 17:52:55 Re: In-order pg_dump (or in-order COPY TO)