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

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitrios Apostolou <jimis(at)gmx(dot)net>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: In-order pg_dump (or in-order COPY TO)
Date: 2025-09-01 19:02:15
Message-ID: 46723eba-bf31-4789-bf50-9f53bc7bdc5f@aklaver.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 9/1/25 10:54, Tom Lane wrote:
> Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> writes:
>> 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.
>
> The TOC is initially written out with zeroes for the offsets.
> Then the per-table data parts are written out, tracking where
> each one begins. At the end, if the output file is seekable,
> pg_dump seeks back to the start and re-writes the whole TOC
> section, now with data offsets populated. But output to a
> pipe won't be seekable.

Got it, thanks.

>
> regards, tom lane

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Albrecht Dreß 2025-09-03 15:40:45 Q: limit the length of log file entries?
Previous Message Tom Lane 2025-09-01 17:54:16 Re: In-order pg_dump (or in-order COPY TO)