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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks
Date: 2020-08-07 17:12:06
Message-ID: 2758889.1596820326@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... So I suggest something more like:

> - * callback. For simplicity, only the latest entry can be
> - * removed. (We could work harder but there is no need for
> - * current uses.)
> + * callback. We only look at the latest entry for removal, as we
> + * expect the caller to use before_shmem_exit callback mechanism
> + * in the LIFO order.

That's a meaningless statement for any one caller. So it needs to be more
like "we expect callers to add and remove temporary before_shmem_exit
callbacks in strict LIFO order".

I wonder whether we ought to change the function to complain if the
last list entry doesn't match. We'd have caught this bug sooner
if it did, and it's not very clear why silently doing nothing is
a good idea when there's no match.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-08-07 17:33:43 Re: [Patch] Optimize dropping of relation buffers using dlist
Previous Message Tom Lane 2020-08-07 16:56:01 Re: Parallel worker hangs while handling errors.