Skip to content

2.27.0.0-b49

2.27.0.0-b49: [#26447] YSQL: Improve Yugabyte/Postgres logging integration
@andrei-mart andrei-mart tagged this 02 May 01:01 
Summary:
- Make use of the ErrorData.backtrace field. PG13 introduced a way to
  attach stack traces to errors and introduced a field in the ErrorData
  structure for that. That solution is nicer than our append to the
  error messages, so we are eliminating yb_additional_errmsg function.
  It seems like ysqlsh/psql does not have a way to display backtrace at
  this time, so backtrace goes to the log only. That sounds like a
  disadvantage, but it should be possible to address this issue.
- The Postgres' backtrace_functions GUC variable now controls if
  backtrace is added to the error or not. The
  yb_debug_report_error_stacktrace GUC variable used for that before is
  repurposed to control if the stacktrace is attached to errors received
  from DocDB. The main reason why it is not fully eliminated is that
  many DocDB errors carry only filename and lineno, but not function
  name. Therefore backtrace_functions can not be used to add stacktrace
  to those.
- Eliminated YBShouldLogStackTraceOnError() function controlling
  stacktraces in the YB log and YB_PG_STACK_TRACE_ON_ERROR environment
  variable. It seems like it was introduced for similar purpose as the
  yb_debug_report_error_stacktrace GUC variable, but later on was
  primarily used in YbGate to log internal Postgres error details.
  Instead, PgGate now logs stacktrace depending on error severity. Severity
  level ERROR or higher now always logged with the stacktrace.
- We use YBCGetStackTrace() to obtain and format the stacktrace by
  default. It outputs filenames and line numbers like this:

```
  ../../../../../../../src/postgres/src/backend/utils/adt/numutils.c:232:                                 @     0x615be6a8c612  pg_strtoint32
  ../../../../../../../src/postgres/src/backend/utils/adt/int.c:293:                                      @     0x615be6a197c0  int4in
  ../../../../../../../src/postgres/src/backend/utils/fmgr/fmgr.c:1579:                                   @     0x615be6b9b79c  InputFunctionCall
  ../../../../../../../src/postgres/src/backend/utils/fmgr/fmgr.c:1710:                                   @     0x615be6b9bd2d  OidInputFunctionCall
  ../../../../../../src/postgres/src/backend/parser/parse_type.c:662:                                     @     0x615be64d36cb  stringTypeDatum

```
as opposed to Postgres' format:
```
  postgres: yugabyte yugabyte 127.0.0.1(39072) SELECT(pg_strtoint32+0x394) [0x5d6f1ec0e64c]
  postgres: yugabyte yugabyte 127.0.0.1(39072) SELECT(int4in+0x28) [0x5d6f1eb9b7c1]
  postgres: yugabyte yugabyte 127.0.0.1(39072) SELECT(InputFunctionCall+0xec) [0x5d6f1ed1d7a8]
  postgres: yugabyte yugabyte 127.0.0.1(39072) SELECT(OidInputFunctionCall+0x4f) [0x5d6f1ed1dd39]
  postgres: yugabyte yugabyte 127.0.0.1(39072) SELECT(stringTypeDatum+0x62) [0x5d6f1e6556cc]

```
Yugabyte variant seems more user friendly, but there may be use cases
when Postgres format is preferable. Hence we are introducing new GUC
variable yb_debug_original_stacktrace_format to switch to Postgres
style when necessary.
- Fixed few minor pg15 rebase bugs.
Jira: DB-15810

Test Plan: Make sure Jenkins results have no regressions

Reviewers: jason

Reviewed By: jason

Subscribers: yql

Tags: #jenkins-ready

Differential Revision: https://phorge.dev.yugabyte.com/D43599
Assets 2
Loading