Re: Change GUC hashtable to use simplehash?
От | Jeff Davis |
---|---|
Тема | Re: Change GUC hashtable to use simplehash? |
Дата | |
Msg-id | 458350a908d9607f7fc2a15407f4405cc454c970.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Change GUC hashtable to use simplehash? (John Naylor <johncnaylorls@gmail.com>) |
Ответы |
Re: Change GUC hashtable to use simplehash?
|
Список | pgsql-hackers |
On Wed, 2024-03-20 at 14:26 +0700, John Naylor wrote: > This was the culprit. The search path cache didn't trigger this when > it went in, but it seems for frontend a read past the end of malloc > fails -fsantize=address. By the same token, I'm guessing the only > reason this didn't fail for backend is because almost all strings > you'd want to use as a hash key won't use a malloc'd external block. > > I found that adding __attribute__((no_sanitize_address)) to > fasthash_accum_cstring_aligned() passes CI. While this kind of > exception is warned against (for good reason), I think it's fine here > given that glibc and NetBSD, and probably others, do something > similar > for optimized strlen(). Before I write the proper macro for that, are > there any objections? Better ideas? It appears that the spelling no_sanitize_address is deprecated in clang[1] in favor of 'no_sanitize("address")'. It doesn't appear to be deprecated in gcc[2]. Aside from that, +1. Regards, Jeff Davis [1] https://clang.llvm.org/docs/AddressSanitizer.html#disabling-instrumentation-with-attribute-no-sanitize-address [2] https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
В списке pgsql-hackers по дате отправления: