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

From Bharath Rupireddy
Subject Re: Issue with cancel_before_shmem_exit while searching to remove a particular registered exit callbacks
Date
Msg-id CALj2ACUsaLiRrtGhrQL9mbB1MQyG7wye+JVjRf2fXq8zVgKcEA@mail.gmail.com
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>)
List pgsql-hackers

On Fri, Jul 24, 2020 at 8:07 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, Jul 24, 2020 at 7:10 AM Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
> > I looked at what actually llvm_shutdown() does? It frees up JIT stacks, also if exists perf related resource, using LLVMOrcDisposeInstance() and LLVMOrcUnregisterPerf(), that were dynamically allocated in llvm_session_initialize through a JIT library function LLVMOrcCreateInstance() [1].
> >
> > It looks like there is no problem in moving llvm_shutdown to either on_shmem_exit() or on_proc_exit().
>
> If it doesn't involve shared memory, I guess it can be on_proc_exit()
> rather than on_shmem_exit().
>
> I guess the other question is why we're doing it at all. What
> resources are being allocated that wouldn't be freed up by process
> exit anyway?
>

LLVMOrcCreateInstance() and LLVMOrcDisposeInstance() are doing new and delete respectively, I just found these functions from the link [1]. But I don't exactly know whether there are any other resources being allocated that can't be freed up by proc_exit(). Tagging @Andres Freund  for inputs on whether we have any problem making llvm_shutdown() a on_proc_exit() callback instead of before_shmem_exit() callback.

And as suggested in the previous mails, we wanted to make it on_proc_exit() to avoid the abort issue reported in this mail chain, however if we take the abort issue fix commit # 303640199d0436c5e7acdf50b837a027b5726594 as mentioned in the previous response[2], then it may not be necessary, right now, but just to be safer and to avoid any of these similar kind of issues in future, we can consider this change as well.

[1] - https://llvm.org/doxygen/OrcCBindings_8cpp_source.html

 LLVMOrcJITStackRef LLVMOrcCreateInstance(LLVMTargetMachineRef TM) {
  TargetMachine *TM2(unwrap(TM));
   Triple T(TM2->getTargetTriple());
   auto IndirectStubsMgrBuilder =
  orc::createLocalIndirectStubsManagerBuilder(T);
   OrcCBindingsStack *JITStack =
  new OrcCBindingsStack(*TM2, std::move(IndirectStubsMgrBuilder));
   return wrap(JITStack);
 }

LLVMErrorRef LLVMOrcDisposeInstance(LLVMOrcJITStackRef JITStack) {
  auto *J = unwrap(JITStack);
  auto Err = J->shutdown();
  delete J;
  return wrap(std::move(Err));
 }

[2] - https://www.postgresql.org/message-id/CALj2ACVwOKZ8qYUsZrU2y2efnYZOLRxPC6k52FQcB3oriH9Kcg%40mail.gmail.com

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Reigning in ExecParallelHashRepartitionFirst
Next
From: Masahiko Sawada
Date:
Subject: Re: Transactions involving multiple postgres foreign servers, take 2