Horton

Re: Change GUC hashtable to use simplehash?

Anton A. Melnikov <a.melnikov@postgrespro.ru>

View thread
From: "Anton A. Melnikov" <a.melnikov@postgrespro.ru>
To: John Naylor <johncnaylorls@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Ants Aasma <ants.aasma@cybertec.at>, Heikki Linnakangas <hlinnaka@iki.fi>, Junwang Zhao <zhjwpku@gmail.com>, jian he <jian.universality@gmail.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Gurjeet Singh <gurjeet@singh.im>, pgsql-hackers@postgresql.org
Date: 2025-01-16T01:15:31Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Silence warning in older versions of Valgrind

  2. Revert "Speed up tail processing when hashing aligned C strings, take two"

  3. Speed up tail processing when hashing aligned C strings, take two

  4. Teach fasthash_accum to use platform endianness for bytewise loads

  5. Add macro to disable address safety instrumentation

  6. Convert uses of hash_string_pointer to fasthash equivalent

  7. Speed up tail processing when hashing aligned C strings

  8. Add helper functions for dshash tables with string keys.

  9. Fix warnings in cpluspluscheck

  10. Further cosmetic review of hashfn_unstable.h

  11. Simplify initialization of incremental hash state

  12. Add optimized C string hashing

  13. Add inline incremental hash functions for in-memory use

  14. Make all Perl warnings fatal

Attachments

Hi, John!

On 19.12.2024 12:48, John Naylor wrote:
> That would actually be a maintenance headache because the function is
> inlined, but here's a better idea: We already have a fallback path for
> when the string is not suitably aligned, or in 32-bit builds. We could
> just use that under Valgrind:
> 
>   static inline size_t
>   fasthash_accum_cstring(fasthash_state *hs, const char *str)
>   {
> -#if SIZEOF_VOID_P >= 8
> +#if SIZEOF_VOID_P >= 8 && !defined(USE_VALGRIND)
> 
> Any objections?

This variant doesn't produce error and helped me to move
further beyond initdb in the some tests under valgrind
and fix a number of bugs.
Thank you very much!

Seems it is possible to exclude much less code from checking
under valgrind and get the same result by replacing the only
function call pg_rightmost_one_pos64() with a valgrind-safe
code. See the attached patch, please.

The pg_rightmost_one_pos64() itself can also be valgrind-safe
in some cases when the last version of its code works.
But i'm not sure if it's worth writing extra preprocessor instructions
to make this small piece of code also checkable under valgrind.
So in the patch i made a simple variant without it.

With the best wishes,

-- 
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company