On 1/15/20 7:39 PM, Robert Haas wrote: > On Wed, Jan 15, 2020 at 6:40 PM Andres Freund <and...@anarazel.de> wrote: >> It's not obvious why the better approach here wouldn't be to just have a >> very simple ereport replacement, that needs to be explicitly included >> from frontend code. It'd not be meaningfully harder, imo, and it'd >> require fewer adaptions, and it'd look more familiar. > > I agree that it's far from obvious that the hacks in the patch are > best; to the contrary, they are hacks. That said, I feel that the > semantics of throwing an error are not very well-defined in a > front-end environment. I mean, in a backend context, throwing an error > is going to abort the current transaction, with all that this implies. > If the frontend equivalent is to do nothing and hope for the best, I > doubt it will survive anything more than the simplest use cases. This > is one of the reasons I've been very reluctant to go do down this > whole path in the first place.
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.
Regards, -- -David da...@pgmasters.net
