From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, 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-07-07 13:44:41 |
Message-ID: | 1519052.1594129481@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> writes:
> Firstly, pg_start_backup registers nonexclusive_base_backup_cleanup as
> on_shmem_exit call back which will
> add this function to the before_shmem_exit_list array which is
> supposed to be removed on pg_stop_backup
> so that we can do the pending cleanup and issue a warning for each
> pg_start_backup for which we did not call
> the pg_stop backup. Now, I executed a query for which JIT is picked
> up, then the the llvm compiler inserts it's
> own exit callback i.e. llvm_shutdown at the end of
> before_shmem_exit_list array. Now, I executed pg_stop_backup
> and call to cancel_before_shmem_exit() is made with the expectation
> that the nonexclusive_base_backup_cleanup
> callback is removed from before_shmem_exit_list array.
I'm of the opinion that the JIT code is abusing this mechanism, and the
right thing to do is fix that. The restriction you propose to remove is
not just there out of laziness, it's an expectation about what safe use of
this mechanism would involve. Un-ordered removal of callbacks seems
pretty risky: it would mean that whatever cleanup is needed is not going
to be done in LIFO order.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2020-07-07 14:01:22 | Re: Binary support for pgoutput plugin |
Previous Message | Pavel Stehule | 2020-07-07 13:16:43 | Re: Default setting for enable_hashagg_disk (hash_mem) |