PostgreSQL 打印详细错误调用栈 - pg_backtrace

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
简介: 标签 PostgreSQL , pg_backtrace , 错误调用栈 , core 背景 PostgreSQL 使用backtrace,让PG的user process支持self-debugging。 NAME backtrace, backtrace_symbols, backtrace_symbols_fd - support for application

标签

PostgreSQL , pg_backtrace , 错误调用栈 , core


背景

PostgreSQL 使用backtrace,让PG的user process支持self-debugging。

NAME
       backtrace, backtrace_symbols, backtrace_symbols_fd - support for application self-debugging

SYNOPSIS
       #include <execinfo.h>

       int backtrace(void **buffer, int size);

       char **backtrace_symbols(void *const *buffer, int size);

       void backtrace_symbols_fd(void *const *buffer, int size, int fd);

支持:

1、打印错误SQL的调用栈内容。

2、了解LONG QUERY正在执行什么,慢在什么地方。 通过发送信号 (SIGINT)。

3、向日志中输出CORE的信息,打印调用栈信息,通过发送信号 (SIGSEGV or SIGBUS)。

This PostgreSQL extension can be used to get more information
about PostgreSQL backend execution when no debugger is available.
It allows to dump stack trace when error is reported or exception is caught.
So there three used cases of using this extension:

1. Find out the source of error. pg_backtrace extension provides
"pg_backtrace.level" GUC which selects error level for which backtrace information
is attached. Default value is ERROR. So once this extension is initialized,
all errors will include backtrace information which is dumped both in log
file and delivered to the client:

postgres=# select count(*)/0.0 from pg_class;  
ERROR:  division by zero  
CONTEXT:  	postgres: knizhnik postgres [local] SELECT(numeric_div+0xbc) [0x7c5ebc]  
	postgres: knizhnik postgres [local] SELECT() [0x5fe4e2]  
	postgres: knizhnik postgres [local] SELECT() [0x610730]  
	postgres: knizhnik postgres [local] SELECT() [0x6115ca]  
	postgres: knizhnik postgres [local] SELECT(standard_ExecutorRun+0x15a) [0x60193a]  
	postgres: knizhnik postgres [local] SELECT() [0x74168c]  
	postgres: knizhnik postgres [local] SELECT(PortalRun+0x29e) [0x742a7e]  
	postgres: knizhnik postgres [local] SELECT() [0x73e922]  
	postgres: knizhnik postgres [local] SELECT(PostgresMain+0x1189) [0x73fde9]  
	postgres: knizhnik postgres [local] SELECT() [0x47d5e0]  
	postgres: knizhnik postgres [local] SELECT(PostmasterMain+0xd28) [0x6d0448]  
	postgres: knizhnik postgres [local] SELECT(main+0x421) [0x47e511]  
	/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f6361a13830]  
	postgres: knizhnik postgres [local] SELECT(_start+0x29) [0x47e589]  

2. Determine current state of backend (assume that there is some long running query
and you do not know where it spends most of time). It is possible to send SIGINT signal
to backend and it print current stack in logfile:

2018-11-12 18:24:12.222 MSK [24457] LOG:  Caught signal 2  
2018-11-12 18:24:12.222 MSK [24457] CONTEXT:  	/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390) [0x7f63624e3390]  
		/lib/x86_64-linux-gnu/libc.so.6(epoll_wait+0x13) [0x7f6361afa9f3]  
		postgres: knizhnik postgres [local] SELECT(WaitEventSetWait+0xbe) [0x71e4de]  
		postgres: knizhnik postgres [local] SELECT(WaitLatchOrSocket+0x8b) [0x71e93b]  
		postgres: knizhnik postgres [local] SELECT(pg_sleep+0x98) [0x7babd8]  
		postgres: knizhnik postgres [local] SELECT() [0x5fe4e2]  
		postgres: knizhnik postgres [local] SELECT() [0x6266a8]  
		postgres: knizhnik postgres [local] SELECT(standard_ExecutorRun+0x15a) [0x60193a]  
		postgres: knizhnik postgres [local] SELECT() [0x74168c]  
		postgres: knizhnik postgres [local] SELECT(PortalRun+0x29e) [0x742a7e]  
		postgres: knizhnik postgres [local] SELECT() [0x73e922]  
		postgres: knizhnik postgres [local] SELECT(PostgresMain+0x1189) [0x73fde9]  
		postgres: knizhnik postgres [local] SELECT() [0x47d5e0]  
		postgres: knizhnik postgres [local] SELECT(PostmasterMain+0xd28) [0x6d0448]  
		postgres: knizhnik postgres [local] SELECT(main+0x421) [0x47e511]  
		/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f6361a13830]  
		postgres: knizhnik postgres [local] SELECT(_start+0x29) [0x47e589]  

3. Get stack trace for SIGSEGV or SIGBUS signals
(if dumping cores is disabled for some reasons):

2018-11-12 18:25:52.636 MSK [24518] LOG:  Caught signal 11  
2018-11-12 18:25:52.636 MSK [24518] CONTEXT:  	/home/knizhnik/postgresql/dist/lib/pg_backtrace.so(+0xe37) [0x7f6358838e37]  
		/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390) [0x7f63624e3390]  
		/home/knizhnik/postgresql/dist/lib/pg_backtrace.so(pg_backtrace_sigsegv+0) [0x7f6358838fb0]  
		postgres: knizhnik postgres [local] SELECT() [0x5fe474]  
		postgres: knizhnik postgres [local] SELECT() [0x6266a8]  
		postgres: knizhnik postgres [local] SELECT(standard_ExecutorRun+0x15a) [0x60193a]  
		postgres: knizhnik postgres [local] SELECT() [0x74168c]  
		postgres: knizhnik postgres [local] SELECT(PortalRun+0x29e) [0x742a7e]  
		postgres: knizhnik postgres [local] SELECT() [0x73e922]  
		postgres: knizhnik postgres [local] SELECT(PostgresMain+0x1189) [0x73fde9]  
		postgres: knizhnik postgres [local] SELECT() [0x47d5e0]  
		postgres: knizhnik postgres [local] SELECT(PostmasterMain+0xd28) [0x6d0448]  
		postgres: knizhnik postgres [local] SELECT(main+0x421) [0x47e511]  
		/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f6361a13830]  
		postgres: knizhnik postgres [local] SELECT(_start+0x29) [0x47e589]  

As far as Postgres extension is loaded and initialized on first access to
its functions, it is necessary to call pg_backtrace_init() function to
be able to use this extension. This function function actually does nothing
and _PG_init() registers signal handlers for SIGSEGV, SIGBUS and SIGINT and
executor run hook which setups exception context.

This extension is using backtrace function which is available at most Unixes.
As it was mentioned in backtrace documentation:

The symbol names may be unavailable without the use of special linker options.  
For systems using the GNU linker, it is necessary to use the -rdynamic  
linker option.  Note that names of "static" functions are not exposed,  
and won't be available in the backtrace.  

Postgres is built without -rdynamic option. This is why not all function addresses
in the stack trace above are resolved. It is possible to use GDB (at development
host with correspondent postgres binaries) or Linux addr2line utility to
get resolve function addresses:

    $ addr2line -e ~/postgresql/dist/bin/postgres -a 0x5fe4e2  
    0x00000000005fe4e2  
    execExprInterp.c:?  

用法

Usage:

create extension pg_backtrace;  
select pg_backtrace_init();  

参考

pg_backtrace

https://github.com/postgrespro/pg_backtrace

 

免费领取阿里云RDS PostgreSQL实例、ECS虚拟机

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
关系型数据库 MySQL Windows
Windows安装Mysql,服务无法启动,错误1053处理
在Windows7操作系统,部署mysql的时候, 无法启动Mysql服务 错误1053:服务没有及时响应启动或控制请求。 以下整理了处理的详细过程
1216 0
Windows安装Mysql,服务无法启动,错误1053处理
|
存储 关系型数据库 MySQL
MySQL出现Data too long for column...(错误号1406)和 Data truncated for column...(错误号1265)
MySQL出现Data too long for column...(错误号1406)和 Data truncated for column...(错误号1265)
961 0
MySQL出现Data too long for column...(错误号1406)和 Data truncated for column...(错误号1265)
|
数据可视化 关系型数据库 MySQL
mysql:解压版MySQL通过SQLyog可视化密码过期问题(错误号码1862)
mysql:解压版MySQL通过SQLyog可视化密码过期问题(错误号码1862)
404 0
mysql:解压版MySQL通过SQLyog可视化密码过期问题(错误号码1862)
|
关系型数据库 MySQL 数据库
MySQL无法启动的问题->MySQL 服务正在启动 . MySQL 服务无法启动。服务没有报告任何错误。 请键入 NET HELPMSG 3534 以获得更多的帮助
注意以上的操作会清除数据库内容及已经创建的数据库用户,会生成一个新的用户root,此用户没有密码🐱‍🏍
400 0
MySQL无法启动的问题->MySQL 服务正在启动 . MySQL 服务无法启动。服务没有报告任何错误。 请键入 NET HELPMSG 3534 以获得更多的帮助
|
消息中间件 数据采集 监控
ELK搭建(七):搭建PostgreSQL慢查询、错误日志监控平台
PostgreSQL是一款功能非常强大的的关系性数据库,适用于需要执行复杂查询的系统。市面上越来越多的公司开始采用PostgreSQL作为主数据库。 今天我们就来讲解如何搭建一个PostgreSQL的慢日志、错误日志监控平台,实时了解到数据库的日志情况,来帮助我们快速排错及优化。
854 0
ELK搭建(七):搭建PostgreSQL慢查询、错误日志监控平台
|
关系型数据库 MySQL 网络安全
【C#】【MySQL】【配置数据源】SSL Connection error 发生一个或多个错误。由于·意外的数据包格式,握手失败
【C#】【MySQL】【配置数据源】SSL Connection error 发生一个或多个错误。由于·意外的数据包格式,握手失败
221 0
【C#】【MySQL】【配置数据源】SSL Connection error 发生一个或多个错误。由于·意外的数据包格式,握手失败
|
关系型数据库 MySQL C++
安装MySQL时报由于找不到VCRUNTIME140_1.dll,无法继续执行代码。重新安装程序可能会解决此问题错误
安装MySQL时报由于找不到VCRUNTIME140_1.dll,无法继续执行代码。重新安装程序可能会解决此问题错误
安装MySQL时报由于找不到VCRUNTIME140_1.dll,无法继续执行代码。重新安装程序可能会解决此问题错误
|
关系型数据库 MySQL 数据库
Navicat连接MySQL数据库报2059错误如何解决?
Navicat连接MySQL数据库报2059错误如何解决?
292 0
Navicat连接MySQL数据库报2059错误如何解决?
|
SQL 关系型数据库 MySQL
mysql操作中 出现You can‘t specify target table for update in FROM clause错误的解决方法
这个错误实际上也不能称之为咱们sql语句写的不行,实际上是我们在一些细节上没有遵循mysql的语法规范。 问题所在:我们一个sql语句中先select这个表,然后再update这个表的内容。 错误示范: UPDATE StuCose SET Grade=60 WHERE Sno IN( SELECT Sno FROM stucose WHERE Grade&lt;=ALL( SELECT MIN(Grade) FROM stucos
423 0
mysql操作中 出现You can‘t specify target table for update in FROM clause错误的解决方法
|
关系型数据库 MySQL 数据库
nivicat复制mysql数据库[Err] [Dtf] 1273 - Unknown collation: 'utf8mb4_0900_ai_ci'错误
问题的原因是两个数据库待转移的表的字符格式不能被被转移数据库识别。例如mysql8的utf8mb4_0900_ai_ci格式再mysql5中就不支持。就需要更改数据库字符编码和各个varchar等字段的编码方式
252 0
nivicat复制mysql数据库[Err] [Dtf] 1273 - Unknown collation: 'utf8mb4_0900_ai_ci'错误

热门文章

最新文章

下一篇
无影云桌面