Re: making the backend's json parser work in frontend code - Mailing list pgsql-hackers

From Andres Freund
Subject Re: making the backend's json parser work in frontend code
Date
Msg-id 20200116192624.yo6aecandxkzf35m@alap3.anarazel.de
Whole thread Raw
In response to Re: making the backend's json parser work in frontend code  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: making the backend's json parser work in frontend code  (David Steele <david@pgmasters.net>)
List pgsql-hackers
Hi,

On 2020-01-16 14:20:28 -0500, Tom Lane wrote:
> David Steele <david@pgmasters.net> writes:
> > The way we handle this in pgBackRest is to put a TRY ... CATCH block in
> > main() to log and exit on any uncaught THROW.  That seems like a
> > reasonable way to start here.  Without memory contexts that almost
> > certainly will mean memory leaks but I'm not sure how much that matters
> > if the action is to exit immediately.
>
> If that's the expectation, we might as well replace backend ereport(ERROR)
> with something that just prints a message and does exit(1).

Well, the process might still want to do some cleanup of half-finished
work. You'd not need to be resistant against memory leaks to do so, if
followed by an exit. Obviously you can also do all the necessarily
cleanup from within the ereport(ERROR) itself, but that doesn't seem
appealing to me (not composable, harder to reuse for other programs,
etc).

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: making the backend's json parser work in frontend code
Next
From: Tomas Vondra
Date:
Subject: Re: SlabCheck leaks memory into TopMemoryContext