| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | John Naylor <johncnaylorls(at)gmail(dot)com>, 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-06 07:43:47 |
| Message-ID: | b1e5047b-e322-4fb5-94f3-474f9425bcaa@iki.fi |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 06/08/2026 01:17, John Naylor wrote:
> 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.
Can you elaborate? Do you think the changes that pg_upgrade makes should
be written somewhere else than WAL, or is this just about the transfer
mode setting, or something else? How would you do it?
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Borodin | 2026-08-06 07:49:26 | Avoid streaming zero-filled WAL switch padding |
| Previous Message | Heikki Linnakangas | 2026-08-06 07:39:41 | Re: [Patch]The Case For WAL-Logging pg_upgrade |