Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks
Date
Msg-id CA+TgmoYgNMc7x814iih==wH-jN-4bO_FH_xWBdV5HEK=6e3kDQ@mail.gmail.com
Whole thread Raw
In response to Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks  (Andres Freund <andres@anarazel.de>)
Responses Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: [PATCH] Covering SPGiST index
Next
From: Robert Haas
Date:
Subject: nested queries vs. pg_stat_activity