| From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
|---|---|
| To: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
| Cc: | Bala M <krishna(dot)pgdba(at)gmail(dot)com>, "adrian(dot)klaver(at)aklaver(dot)com" <adrian(dot)klaver(at)aklaver(dot)com>, chris+google(at)qwirx(dot)com, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication) |
| Date: | 2025-10-24 16:25:04 |
| Message-ID: | CA+bJJbwSZg6fiQ78N-_2NwRBbp=6e5WjnSX9SPa_DOxnaU63Vg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, 23 Oct 2025 at 17:21, Greg Sabino Mullane <htamfids(at)gmail(dot)com> wrote
pg_dump is the most reliable, and the slowest. Keep in mind that only the
> actual data needs to move over (not the indexes, which get rebuilt after
> the data is loaded). You could also mix-n-match pg_logical and pg_dump if
> you have a few tables that are super large. Whether either approach fits in
> your 24 hour window is hard to say without you running some tests.
>
Long time ago I had a similar problem and did a "running with scissors"
restore. This means:
1.- Prepare normal configuration, test, etc for the new version.
2.- Prepare a restore configuration, with fsync=off, wallevel=minimal,
whatever option gives you any speed advantage.
As the target was empty, if restore failed we could just clean and restart.
3.- Dump, boot with the restore configuration, restore, clean shutdown,
switch to production configuration, boot again and follow on.
Time has passed and I lost my notes, but I remember the restore was much
faster than doing it with the normal production configuration. Given
current machine speeds, it maybe doable.
Francisco Olarte.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2025-10-24 22:37:55 | Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication) |
| Previous Message | Adrian Klaver | 2025-10-24 15:51:17 | Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication) |