Re: pg_upgrade: Support for upgrading to checksums enabled
От | Peter Eisentraut |
---|---|
Тема | Re: pg_upgrade: Support for upgrading to checksums enabled |
Дата | |
Msg-id | 3f5c021a-31cf-4d40-a3a2-c7a588ba1269@eisentraut.org обсуждение исходный текст |
Ответ на | Re: pg_upgrade: Support for upgrading to checksums enabled (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: pg_upgrade: Support for upgrading to checksums enabled
|
Список | pgsql-hackers |
On 11.03.25 11:42, Peter Eisentraut wrote: > Here is an updated patch that works more along those lines. It adds a > pg_upgrade option --update-checksums, which activates the code to > rewrite the checksums. You must specify this option if the source and > target clusters have different checksum settings. > > Note that this also works to hypothetically upgrade between future > different checksum versions (hence "--update-*", not "--enable-*"). > Also, as the patch is currently written, it is also required to specify > this option to downgrade from checksums to no-checksums. (It will then > write a zero into the checksum place, as it would look if you had never > used checksums.) Also, you can optionally specify this option even if > the checksum settings are the same, then it will recalculate the > checksums. Probably not all of this is useful, but perhaps a subset of > it. Thoughts? > > Also, I still don't know what to do about the Windows code path in > copyFile(). We could just not support this feature on Windows? Or > maybe the notionally correct thing to do would be to move that code into > copyFileByRange(). But then we'd need a different default on Windows > and it would require more documentation. I don't know what to do here > and I don't have enough context to make a suggestion. But if we don't > answer this, I don't think we can move ahead with this feature. I'm not sensing much enthusiasm for this feature or for working out the remaining problems, so I'm closing this commitfest entry.
В списке pgsql-hackers по дате отправления: