Re: pgsql: dshash: Add sequential scan support.
От | Andres Freund |
---|---|
Тема | Re: pgsql: dshash: Add sequential scan support. |
Дата | |
Msg-id | 20220311012712.botrpsikaufzteyt@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pgsql: dshash: Add sequential scan support. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: