On Tue, Apr 21, 2020 at 4:59 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Alexander Korotkov <a.korot...@postgrespro.ru> writes: > > On Tue, Apr 21, 2020 at 7:58 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Yeah, but that was for a security hole. I am doubtful that the > >> severity of this problem is bad enough to justify jumping through > >> similar hoops. Even if we fixed it and documented it, how many > >> users would bother to apply the manual correction? > > > Sure, only most conscious users will do the manual correction. But if > > there are only two option: backpatch it this way or don't backpatch at > > all, then I would choose the first one. > > Well, if it were something that you could just do and forget, then > maybe. But actually, you are proposing to invest a lot of *other* > people's time --- notably me, as the likely author of the next > set of release notes --- so it's not entirely up to you.
Sure, this is not entirely up to me. > Given the lack of field complaints, I'm still of the opinion that > this isn't really worth back-patching. So, what exact strategy do you propose? I don't like idea to postpone decision of what we do with backbranches. We may decide not to fix it in previous releases. But in order to handle this decision correctly I think we should document this bug there. I'm OK with doing this. And I can put my efforts on fixing it in the head and backpatching the documentation. But does this save significant resources in comparison with fixing bug in backbranches? ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company