Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks
| От | Robert Haas |
|---|---|
| Тема | Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks |
| Дата | |
| Msg-id | CA+TgmoYgNMc7x814iih==wH-jN-4bO_FH_xWBdV5HEK=6e3kDQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks
|
| Список | pgsql-hackers |
On Fri, Aug 7, 2020 at 5:20 PM Andres Freund <andres@anarazel.de> wrote: > In which situations is the removal actually useful *and* safe, with > these constraints? You'd have to have a very narrow set of functions > that are called while the exit hook is present, i.e. basically this > would only be usable for PG_ENSURE_ERROR_CLEANUP and nothing else. And > even there it seems like it's pretty easy to get into a situation where > it's not safe. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: