Back patch of Remove durable_rename_excl()
Hi,
I noticed that the corruption issue related to two hardlinks pointing
to the same WAL file has been fixed in the master branch up to version
16 in commit [1]https://github.com/postgres/postgres/commit/dac1ff30906b9cef7859380905d038892b32968b. As a result, the function durable_rename_excl()
became unused and was removed in commit [2]https://github.com/postgres/postgres/commit/eb64ceac7ec3422f2370b8824dce62ee8fe52dca. Since this corruption
issue is occurring in older versions, commit [1]https://github.com/postgres/postgres/commit/dac1ff30906b9cef7859380905d038892b32968b has been backported
for versions 13 to 15 in commit [3]https://github.com/postgres/postgres/commit/c1c9df3159cfa91416bebe56ae50bc32d8a4e10b. However, I don't see the
backporting for commit [2]https://github.com/postgres/postgres/commit/eb64ceac7ec3422f2370b8824dce62ee8fe52dca. Is there a specific reason for this? If
not, I would suggest backporting commit [2]https://github.com/postgres/postgres/commit/eb64ceac7ec3422f2370b8824dce62ee8fe52dca for versions 13 to 15 as
well.
[1]: https://github.com/postgres/postgres/commit/dac1ff30906b9cef7859380905d038892b32968b
[2]: https://github.com/postgres/postgres/commit/eb64ceac7ec3422f2370b8824dce62ee8fe52dca
[3]: https://github.com/postgres/postgres/commit/c1c9df3159cfa91416bebe56ae50bc32d8a4e10b
Best Regards,
Nitin Jadhav
Azure Database for PostgreSQL
Microsoft
Nitin Jadhav <nitinjadhavpostgres@gmail.com> writes:
I noticed that the corruption issue related to two hardlinks pointing
to the same WAL file has been fixed in the master branch up to version
16 in commit [1]. As a result, the function durable_rename_excl()
became unused and was removed in commit [2]. Since this corruption
issue is occurring in older versions, commit [1] has been backported
for versions 13 to 15 in commit [3]. However, I don't see the
backporting for commit [2]. Is there a specific reason for this?
Fear of breaking extensions that use the function, perhaps?
We don't like to break ABI in minor releases.
regards, tom lane
On Mon, Jan 27, 2025 at 09:47:22AM -0500, Tom Lane wrote:
Nitin Jadhav <nitinjadhavpostgres@gmail.com> writes:
I noticed that the corruption issue related to two hardlinks pointing
to the same WAL file has been fixed in the master branch up to version
16 in commit [1]. As a result, the function durable_rename_excl()
became unused and was removed in commit [2]. Since this corruption
issue is occurring in older versions, commit [1] has been backported
for versions 13 to 15 in commit [3]. However, I don't see the
backporting for commit [2]. Is there a specific reason for this?Fear of breaking extensions that use the function, perhaps?
We don't like to break ABI in minor releases.
Yup [0]/messages/by-id/20220418182336.GA2298576@nathanxps13. It'd be nice if we could get folks to stop using it, but that
doesn't seem worth the ABI breakage, and from a couple of web searches,
there doesn't seem to be much external use, anyway. IMHO letting it slowly
phase out as versions go out of support is sufficient in this case.
[0]: /messages/by-id/20220418182336.GA2298576@nathanxps13
--
nathan
Thank you for providing the details. I agree to the concern about
breaking extensions that depend on the function. Gradually phasing it
out as versions become unsupported seems like a sensible approach.
Best Regards,
Nitin Jadhav
Azure Database for PostgreSQL
Microsoft
Show quoted text
On Mon, Jan 27, 2025 at 8:43 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
On Mon, Jan 27, 2025 at 09:47:22AM -0500, Tom Lane wrote:
Nitin Jadhav <nitinjadhavpostgres@gmail.com> writes:
I noticed that the corruption issue related to two hardlinks pointing
to the same WAL file has been fixed in the master branch up to version
16 in commit [1]. As a result, the function durable_rename_excl()
became unused and was removed in commit [2]. Since this corruption
issue is occurring in older versions, commit [1] has been backported
for versions 13 to 15 in commit [3]. However, I don't see the
backporting for commit [2]. Is there a specific reason for this?Fear of breaking extensions that use the function, perhaps?
We don't like to break ABI in minor releases.Yup [0]. It'd be nice if we could get folks to stop using it, but that
doesn't seem worth the ABI breakage, and from a couple of web searches,
there doesn't seem to be much external use, anyway. IMHO letting it slowly
phase out as versions go out of support is sufficient in this case.[0] /messages/by-id/20220418182336.GA2298576@nathanxps13
--
nathan