On Wed, Sep 28, 2022 at 10:19 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> writes:
> > I had the same opinion. Here's what I think - for backup functions, we
> > can have the new memory context child of TopMemoryContext and for
> > perform_base_backup(), we can have the memory context child of
> > CurrentMemoryContext. With PG_TRY()-PG_FINALLY()-PG_END_TRY(), we can
> > delete those memory contexts upon ERRORs. This approach works for us
> > since backup-related code doesn't have any FATALs.
>
> Not following your last point here? A process exiting on FATAL
> does not especially need to clean up its memory allocations first.
> Which is good, because "backup-related code doesn't have any FATALs"
> seems like an assertion with a very short half-life.
You're right. My bad. For FATALs, we don't need to clean the memory as
the process itself exits.
* Note: an ereport(FATAL) will not be caught by this construct; control will
* exit straight through proc_exit().
/*
* Perform error recovery action as specified by elevel.
*/
if (elevel == FATAL)
{
/*
* Do normal process-exit cleanup, then return exit code 1 to indicate
* FATAL termination. The postmaster may or may not consider this
* worthy of panic, depending on which subprocess returns it.
*/
proc_exit(1);
}
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
