Re: pgsql: dshash: Add sequential scan support.
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>
Cc: pgsql-committers@lists.postgresql.org, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Date: 2022-03-11T01:27:12Z
Lists: pgsql-hackers
Hi, On 2022-03-10 20:09:56 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > dshash: Add sequential scan support. > > Add ability to scan all entries sequentially to dshash. The interface is > > similar but a bit different both from that of dynahash and simple dshash > > search functions. The most significant differences is that dshash's interfac > > always needs a call to dshash_seq_term when scan ends. > > Umm ... what about error recovery? Or have you just cemented the > proposition that long-lived dshashes are unsafe? I don't think this commit made it worse. dshash_seq_term() releases an lwlock (which will be released in case of an error) and unsets hash_table->find_[exclusively_]locked. The latter weren't introduced by this patch, and are also set by dshash_find(). I agree that ->find_[exclusively_]locked are problematic from an error recovery perspective. It's per-backend state at least and just used for assertions. We could remove it. Or stop checking it in places where it could be set wrongly: dshash_find() and dshash_detach() couldn't check anymore, but the rest of the assertions would still be valid afaics? Greetings, Andres Freund
Commits
-
Fix lock assertions in dshash.c.
- eed959a457ea 16.0 landed
- 53df1e28d2f7 15.0 landed
- cd26139a3056 11.17 landed
- 4f88dbac22a8 12.12 landed
- 7cdd0c2d7cdf 13.8 landed
- 5e7608e81ebb 14.5 landed
-
dshash: Add sequential scan support.
- 352d297dc74f 15.0 cited