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

From Tom Lane
Subject Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks
Date
Msg-id 3195298.1597070661@sss.pgh.pa.us
Whole thread Raw
In response to Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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



pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: Add Information during standby recovery conflicts
Next
From: Magnus Hagander
Date:
Subject: Re: nested queries vs. pg_stat_activity