At Mon, 4 Jul 2022 14:55:43 +1200, Thomas Munro <thomas.mu...@gmail.com> wrote in > [Re-directing to -hackers] > > On Fri, Mar 11, 2022 at 2:27 PM Andres Freund <and...@anarazel.de> wrote: > > 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? > > Yeah, it's all for assertions... let's just remove it. Those > assertions were useful to me at some stage in development but won't > hold as well as I thought, at least without widespread PG_FINALLY(), > which wouldn't be nice. > > *dsa_get_address() might need to adjust the memory map with system > calls, which might fail. If you think of DSA as not only an allocator > but also a poor man's user level virtual memory scheme to tide us over > until we get threads, then this is a pretty low level kind of > should-not-happen failure that is analogous on some level to SIGBUS or > SIGSEGV or something like that, and we should PANIC. Then we could > claim that dsa_get_address() is no-throw. At least, that was one > argument I had with myself while investigating that strange Solaris > shm_open() failure, but ... I lost the argument. It's quite an > extreme position to take just to support these assertions, which are > of pretty limited value. > > [1] > https://www.postgresql.org/message-id/20220701232009.jcwxpl45bptaxv5n%40alap3.anarazel.de
FWIW, the discussion above is convincing to me and the patch looks good. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
