On Tue, Apr 21, 2020 at 4:59 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> > On Tue, Apr 21, 2020 at 7:58 AM Tom Lane <tgl@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
