Thread: 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]. 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? If not, I would suggest backporting commit [2] 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]. 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] https://postgr.es/m/20220418182336.GA2298576%40nathanxps13 -- 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 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] https://postgr.es/m/20220418182336.GA2298576%40nathanxps13 > > -- > nathan