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: Andres Freund <andres(at)anarazel(dot)de>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, 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-10 19:41:33
Message-ID: 3250875.1597088493@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:
> Perhaps we really have four categories here:
> (1) Temporary handlers for PG_ENSURE_ERROR_CLEANUP().
> (2) High-level cleanup that needs to run after aborting out of the
> current transaction.
> (3) Per-subsystem shutdown for shared memory stuff.
> (4) Per-subsystem shutdown for backend-private stuff.

Hmm, I don't think we actually have any of (2) do we? Or at least
we aren't using ipc.c callbacks for them.

> What I do think we should do, after thinking about it more,
> is discourage the casual use of before_shmem_exit() for things where
> on_shmem_exit() or on_proc_exit() would be just as good. I think
> that's what would avoid the most problems here.

I think we're mostly in violent agreement here. The interesting
question seems to be Andres' one about whether before_shmem_exit
actually has any safe use except for PG_ENSURE_ERROR_CLEANUP.
It may not, in which case perhaps we oughta rename it?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-08-10 19:50:19 Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks
Previous Message Robert Haas 2020-08-10 19:33:15 Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks