From aa5c2c30fd60a89db51e2ba3f64f9a962f6d40e5 Mon Sep 17 00:00:00 2001 From: Craig Ringer Date: Thu, 3 Sep 2020 12:53:55 +0800 Subject: [PATCH 4/9] Document that generally PG_CATCH() should PG_RE_THROW() --- src/include/utils/elog.h | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/src/include/utils/elog.h b/src/include/utils/elog.h index 95844de850..1552366477 100644 --- a/src/include/utils/elog.h +++ b/src/include/utils/elog.h @@ -307,7 +307,9 @@ extern void check_errcontext_stack_on_return(const ErrorContextCallback * const * } * PG_CATCH(); * { - * ... error recovery code ... + * ... local error handling code ... + * // In most cases you must re-propagate the error: + * PG_RE_THROW(); * } * PG_END_TRY(); * @@ -336,6 +338,12 @@ extern void check_errcontext_stack_on_return(const ErrorContextCallback * const * You cannot use both PG_CATCH() and PG_FINALLY() in the same * PG_TRY()/PG_END_TRY() block. * + * Important: PG_CATCH() does not do any cleanup of memory contexts, executor + * and transaction state, etc. You can NOT just PG_CATCH() arbitrary errors and + * continue normal execution without a PG_RE_THROW(). See the block following + * the sigsetjmp() call in PostgresMain() for an example of how cleanup of + * backend state after an error may be performed. + * * Note: while the system will correctly propagate any new ereport(ERROR) * occurring in the recovery section, there is a small limit on the number * of levels this will work for. It's best to keep the error recovery -- 2.26.2