Horton

Re: Change GUC hashtable to use simplehash?

John Naylor <johncnaylorls@gmail.com>

View thread
From: John Naylor <johncnaylorls@gmail.com>
To: "Anton A. Melnikov" <a.melnikov@postgrespro.ru>
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: 2024-12-19T03:21:39Z
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

On Thu, Dec 19, 2024 at 7:10 AM Anton A. Melnikov
<a.melnikov@postgrespro.ru> wrote:
> Found that https://github.com/postgres/postgres/commit/0aba2554409ee3251d7558567edd114d8ed36dcc
> produces a valgrind error in initdb.

What architecture and valgrind version is this? We've been bitten
before by different results on Arm vs x86.

The offending code is not even my preferred way to handle the last
word of the string (see f4ad0021af), so if the current way is still
not valgrind-clean, I wonder if we should give up and add an
exception, since we know any garbage bits are masked off.

-- 
John Naylor
Amazon Web Services