Re: Back-patch is necessary? Re: Don't try fetching future segment ofa TLI.
От | Fujii Masao |
---|---|
Тема | Re: Back-patch is necessary? Re: Don't try fetching future segment ofa TLI. |
Дата | |
Msg-id | 9c76bcab-1804-8c91-b834-5876ae72b9fb@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Back-patch is necessary? Re: Don't try fetching future segment ofa TLI. (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Back-patch is necessary? Re: Don't try fetching future segment ofa TLI.
Re: Back-patch is necessary? Re: Don't try fetching future segment ofa TLI. |
Список | pgsql-hackers |
On 2020/05/07 17:57, Amit Kapila wrote: > On Thu, May 7, 2020 at 12:13 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote: >> >> On 2020/05/02 20:40, Amit Kapila wrote: >>> >>> I don't see any obvious problem with the changed code but we normally >>> don't backpatch performance improvements. I can see that the code >>> change here appears to be straight forward so it might be fine to >>> backpatch this. Have we seen similar reports earlier as well? AFAIK, >>> this functionality is for a long time and if people were facing this >>> on a regular basis then we would have seen such reports multiple >>> times. I mean to say if the chances of this hitting are less then we >>> can even choose not to backpatch this. >> >> I found the following two reports. ISTM there are not so many reports... >> https://www.postgresql.org/message-id/16159-f5a34a3a04dc67e0@postgresql.org >> https://www.postgresql.org/message-id/dd6690b0-ec03-6b3c-6fac-c963f91f87a7%40postgrespro.ru >> > > The first seems to be the same where this bug has been fixed. It has > been moved to hackers in email [1]. Yes, that's the original report that leaded to the commit. > Am, I missing something? > Considering it has been encountered by two different people, I think > it would not be a bad idea to back-patch this. +1 So I will do the back-patch. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: