From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_dump -Z6 (the default) can be pretty slow |
Date: | 2023-10-19 00:00:31 |
Message-ID: | 45e16ff2-da2d-46c3-be52-03cad8eb60a3@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On 10/18/23 18:42, Scott Ribe wrote:
>> On Oct 18, 2023, at 5:21 PM, Ron<ronljohnsonjr(at)gmail(dot)com> wrote:
>>
>> It didn't occur to me to mention that I used it. Do people really still not use -Fd?
> I don't know--I guess it depends on context. Certainly for upgrades I don't know any reason not to.
Even for nightly backups (we still use pg_dump instead of pgbackrest on a
few smaller systems), I always use directory format backups.
>> I'm still using 9.6, so that feature isn't available yet. When I get the Pg 15 VMs stood up (Pg15 binaries are not available for RHEL 6), I'm definitely going to try that.
> I thought of that mere seconds after posting my prior reply ;-)
>
> Have you considered pg_upgrade?
Since "the migrated databases will be on new servers, and we purge off old
partitions and add new partitions, pg_upgrade and logical replication are
off the table".
And, of course, 9.6 binaries aren't available at all (at least I can't find
9.6.24 RPMs anywhere under https://download.postgresql.org/pub/) so
rsyncing the database files to the new server and then doing a pg_upgrade
won't work. Even then, I'd have to rebuild many indices anyway, due to glibc
locale changes.
--
Born in Arizona, moved to Babylonia.
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2023-10-19 04:25:58 | Re: Tools available to determine bad code in the testing phase |
Previous Message | Scott Ribe | 2023-10-18 23:42:51 | Re: pg_dump -Z6 (the default) can be pretty slow |