Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Well, I don't really care whether or not we change this function to
> iterate over the callback list or whether we add a warning that you
> need to use it in LIFO order, but I think we should do one or the
> other, because this same confusion has come up multiple times. I
> thought that Tom was opposed to making it iterate over the callback
> list (for reasons I don't really understand, honestly) so adding a
> comment and a cross-check seemed like the practical option. Now I also
> think it's fine to iterate over the callback list: this function
> doesn't get used so much that it's likely to be a performance problem,
> and I don't think this is the first bug that would have become a
> non-bug had we done that years and years ago whenever it was first
> proposed. In fact, I'd go so far as to say that the latter is a
> slightly better option. However, doing nothing is clearly worst.

I agree that doing nothing seems like a bad idea. My concern about
allowing non-LIFO callback removal is that it seems to me that such
usage patterns have likely got *other* bugs, so we should discourage
that. These callbacks don't exist in a vacuum: they reflect that
the mainline code path has set up, or torn down, important state.
Non-LIFO usage requires very strong assumptions that the states in
question are not interdependent, and that's something I'd rather not
rely on if we don't have to.

regards, tom lane