Re: In-order pg_dump (or in-order COPY TO)
От | Adrian Klaver |
---|---|
Тема | Re: In-order pg_dump (or in-order COPY TO) |
Дата | |
Msg-id | 0dc17a73-2372-4613-a50e-610ae7d02b93@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/27/25 09:10, Dimitrios Apostolou wrote: > > On Wednesday 2025-08-27 17:25, Adrian Klaver wrote: >> >> For completeness and just in case they may affect the output what do >> the patches do? > > Two patches for speeding up scanning an archive without TOC, like the > one I'm having (because it is piped into borg, instead of written to > file). These were activated, but shouldn't matter. They only build the > TOC in pg_restore's memory. Are you sure about that? I just did: pg_dump -Fc --compress=none --no-toast-compression -d test -U postgres | borg create --stats --stdin-name pg_file --stdin-user aklaver --stdin-group aklaver borg_test/::PgTest - Then: borg mount borg_test/ mnt_tmp/ cd mnt_tmp/PgTest/ and then: pg_restore -l pg_file and I got a TOC. Or are you streaming the data out of the Borg archive? > > https://commitfest.postgresql.org/patch/5809/ > https://commitfest.postgresql.org/patch/5817/ > > And two patches for speeding up pg_restore like mentioned above, under > specific arguments that I didn't provide. (one speedup needs --clean, > and the other needs --freeze). > > https://commitfest.postgresql.org/patch/5821/ > https://commitfest.postgresql.org/patch/5826/ > > IIRC I did not activate them (via --clean) because TRUNCATE fails when > foreign keys exist. See the discussion threads. > > > Dimitris -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: