| From: | John Naylor <johncnaylorls(at)gmail(dot)com> |
|---|---|
| To: | Bohyun Lee <bohyun(dot)lee(at)databricks(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [Patch]The Case For WAL-Logging pg_upgrade |
| Date: | 2026-08-05 22:17:16 |
| Message-ID: | CANWCAZb8vi_x=nkpOZXW8Nc8-T2VeNj-zZH37-1bQ4+nbgHwbQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 5, 2026 at 9:36 PM Bohyun Lee <bohyun(dot)lee(at)databricks(dot)com> wrote:
> The GUCs are introduced because we cannot assume the standby's storage layout exactly matches the primary's, neither where the retained pre-upgrade directory sits, nor how its files are physically placed.
> It also depends on how the cluster intends to use the standby. For instance, if the operator wants to keep the standby as a rollback target, it may be worthwhile to use a different transfer mode via the newly introduced pg_upgrade_standby_transfer_mode GUC, which I believe is useful.
> Nevertheless, the reconstructed cluster will be logically identical, even if the physical representation diverges.
Given the above design concepts, I still think WAL is fundamentally
the wrong mechanism for this.
BTW, you top-posted again. Please read the link I sent earlier and
trim your replies.
--
John Naylor
Amazon Web Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2026-08-05 23:33:34 | Whole row var issue |
| Previous Message | Michael Paquier | 2026-08-05 22:16:43 | Re: Fix archive restore race that could unlink WAL before rename |