Re: BufferAlloc: don't take two simultaneous locks - Mailing list pgsql-hackers

From Michail Nikolaev
Subject Re: BufferAlloc: don't take two simultaneous locks
Date
Msg-id CANtu0ohTqkVYCFyHRM6uG=jO=j_9MkQMrh04YPVt57rL5sTykA@mail.gmail.com
Whole thread Raw
In response to Re: BufferAlloc: don't take two simultaneous locks  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: BufferAlloc: don't take two simultaneous locks
List pgsql-hackers
Hello, Yura.

Test results look promising. But it seems like the naming and dynahash
API change is a little confusing.

1) I think it is better to split the main part and atomic nentries
optimization into separate commits.
2) Also, it would be nice to also fix hash_update_hash_key bug :)
3) Do we really need a SIZEOF_LONG check? I think pg_atomic_uint64 is
fine these days.
4) Looks like hash_insert_with_hash_nocheck could potentially break
the hash table. Is it better to replace it with
hash_search_with_hash_value with HASH_ATTACH action?
5) In such a case hash_delete_skip_freelist with
hash_search_with_hash_value with HASH_DETTACH.
6) And then hash_return_to_freelist -> hash_dispose_dettached_entry?

Another approach is a new version of hash_update_hash_key with
callbacks. Probably it is the most "correct" way to keep a hash table
implementation details closed. It should be doable, I think.

Thanks,
Michail.



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Why is INSERT-driven autovacuuming based on pg_class.reltuples?
Next
From: Tom Lane
Date:
Subject: Re: Support tab completion for upper character inputs in psql