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
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 |