| From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
|---|---|
| To: | Dimitrios Apostolou <jimis(at)gmx(dot)net>, Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Experience and feedback on pg_restore --data-only |
| Date: | 2025-03-25 15:27:13 |
| Message-ID: | e2360771-b2e4-419d-8d55-f832ea815952@aklaver.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 3/24/25 09:15, Dimitrios Apostolou wrote:
> Hi Ron,
>
> I read your reply in the mailing list archives as I'm not subscribed to
> the list, and I'm copy-pasting a response here. Please include me as a
> recipient in further replies.
>
>> Why are you regularly having emergencies requiring the restoration of
>> multi-TB tables to databases with lots of cruft?
>>
>> Fixing that would go a long way towards eliminating your problems with
>> pg_restore.
>
> I don't have emergencies yet. I'm testing the process of restoring the
> database dump, and it takes more than 24 hours currently. A successful
> test is vital to approve the process.
It is doubtful that pg_dump/pg_restore will meet the requirements. You
are probably looking at some process that does incremental updates and
then restores from that. Something like pgbackrest:
comes to mind.
>
> But the primary usage of pg_restore that I have is not to save me from
> emergencies but to populate the dev database with recent data.
>
>
> Regards,
> Dimitris
>
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christoph Berg | 2025-03-25 15:41:06 | Re: query_id: jumble names of temp tables for better pg_stat_statement UX |
| Previous Message | Sami Imseih | 2025-03-25 14:59:34 | Re: query_id: jumble names of temp tables for better pg_stat_statement UX |