Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode
От
Michael Paquier
Тема
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode
Дата
Msg-id
YRswUUro+PzK52Q3@paquier.xyz
Ответ на
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode (Ranier Vilela)
Список
Дерево обсуждения
PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Hans Buschmann <buschmann@nidsa.net>
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Ranier Vilela <ranier.vf@gmail.com>
AW: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Hans Buschmann <buschmann@nidsa.net>
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Ranier Vilela <ranier.vf@gmail.com>
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Michael Paquier <michael@paquier.xyz>
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Ranier Vilela <ranier.vf@gmail.com>
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Michael Paquier <michael@paquier.xyz>
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Tom Lane <tgl@sss.pgh.pa.us>
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Bruce Momjian <bruce@momjian.us>
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Julien Rouhaud <rjuju123@gmail.com>
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Michael Paquier <michael@paquier.xyz>
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Michael Paquier <michael@paquier.xyz>
Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode Michael Paquier <michael@paquier.xyz>
On Mon, Aug 16, 2021 at 02:06:31PM -0300, Ranier Vilela wrote: > uint64 and size_t in 64 bits are equivalents. > uint64 and size_t in 32 bits can be weird, but anyway size_t at 32 bits can > handle 1GB. There is usually a reason why things are done as they are, so before suggesting changing something I would advise to read the threads that created those changes more carefully because they could be mentioned. In this case, we are talking about aef8948, and this part of its related thread: https://www.postgresql.org/message-id/20210105034739.GG7432@momjian.us > base64.c can be made in another patch. This file is a set of code paths used by authentication and SCRAM, it will never get as hot as the code paths that Hans has reported as these are one-time operations. Please note as well cfc40d3 for the reasons why things are handled this way. We absolutely have to use safe routines here. -- Michael
В списке pgsql-hackers по дате отправления
От: Greg Nancarrow
Дата: