Re: B-Tree support function number 3 (strxfrm() optimization)
От | Robert Haas |
---|---|
Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
Дата | |
Msg-id | CA+TgmoYbgGG-8WLD8J_2_AK22Pkx-QZeRMzKRvr3eWY5c8UctQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: B-Tree support function number 3 (strxfrm() optimization) (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: B-Tree support function number 3 (strxfrm() optimization)
|
Список | pgsql-hackers |
On Thu, Aug 7, 2014 at 4:19 PM, Peter Geoghegan <pg@heroku.com> wrote: > On Thu, Aug 7, 2014 at 12:17 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> Gah. Hit send to soon. Also, as much as I'd prefer to avoid >> relitigating the absolutely stupid debate about how to expand the >> buffers, this is no good: >> >> + tss->buflen1 = Max(len1 + 1, tss->buflen1 * 2); >> >> If the first expansion is for a string >512MB and the second string is >> longer than the first, this will exceed MaxAllocSize and error out. > > Fair point. I think this problem is already present in a few existing > places, but it shouldn't be. I suggest this remediation: > >> + tss->buflen1 = Max(len1 + 1, Min(tss->buflen1 * 2, (int) MaxAllocSize)); > > I too would very much prefer to not repeat that debate. :-) Committed that way. As the patch is by and large the same as what I submitted for this originally, I credited myself as first author and you as second author. I hope that seems fair. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: