POSTGRESQL 15 日志的JSON 格式 为什么用JSON 与 PG 14 没有注意的一些参数

POSTGRESQL 的日志与他的竞品 MYSQL 日志可谓是两个极端，一个是根据日志的类别来产生不同的日志，错误日志，慢查询日志，genernal log, 而PG 自开始，日志就只有一个，但日志里面的信息，却是这么多年操作过的数据库中最完全的，没有之一。

大到慢查询日志，整体操作的数据命令以及他们的操作时间，小到各种checkpoint 记录等等，所以通过POSTGRESQL 的日志就可以满足所有对POSTGRESQL 监控状态和了解运行情况的需求。

那么这就产生了一个问题，这些日志的信息我怎么分析的问题，太多了，太详细了，太太太了。

所以日志如何分析必然是一个要解决的问题，所以个人猜想一个做数据库的TEAM 必然要想想后面的POSTGRESQL 日志怎么搞，首先第一个问题就是铺垫，让日志成为一个格式，一个通用的格式，然后固定格式，通过固定的格式在去产生一个 好的，或者第三方的日志处理工具，就好办了。

所以POSTGRESQL 的JSON 日志功能在PG 15 推出了，并且我相信后面无论是官方，还是第三方，或者商业机构会在这里上面做出 “文章”， 对日志的分析工具会有新的 TOOLS。

这里摘取一段 2022年一月17日 Michael Paquier 的关于JSONLOG 的介绍，首先jsonlog 是添加在log_destination 的一个选项，提供了日志的JSON格式。

其中麦克提到了，这个功能就是为了一些其他的应用做一个钩子hook ，来通过日志中发现问题，当然也可以是一个插件。其中在 log_destination 中展示的是jsonlog 说明已经启用了 jsonlog

然后日志可以通过其他的工具来进行打印，甚至可以将JSON 的日志数据，直接写入到 MONGODB ，如果你有大量的postgresql 的数据库需要管理，将这些日志进行集中处理和分析储存，是一个好的管理的方法。

关于这部分的文字可以参考下面的连接

https://www.depesz.com/2022/01/17/waiting-for-postgresql-15-introduce-log_destinationjsonlog/

下面是这个JSON日志的固定的格式，

Key name Type Description timestamp string Time stamp with milliseconds user string User name dbname string Database name pid number Process ID remote_host string Client host remote_port number Client port session_id string Session ID line_num number Per-session line number ps string Current ps display session_start string Session start time vxid string Virtual transaction ID txid string Regular transaction ID error_severity string Error severity state_code string SQLSTATE code message string Error message detail string Error message detail hint string Error message hint internal_query string Internal query that led to the error internal_position number Cursor index into internal query context string Error context statement string Client-supplied query string cursor_position string Cursor index into query string func_name string Error location function name file_name string File name of error location file_line_num number File line number of the error location application_name string Client application name backend_type string Type of backend leader_pid number Process ID of leader for active parallel workers query_id number Query ID

其实JSON 日志的问题，后面在使用中的不断的分析其中的信息，然后做出相关的分析日志的工具。

另一个问题是,PG14 中我之前没有注意的一些参数 如 min_dynamic_ shared_ memory，这个选项是出自于POSTGRESQL 14 的一个新的参数，这个参数的主要对于在数据库启动的时候，需要分配多少内存给并行查询，当此内存区域不足或被并发查询耗尽内存时，新的并行查询尝试使用dynamic_shared_memory_type配置的方法从操作系统临时分配额外的共享内存，由于内存管理开销，该方法可能会较慢。在启动时使用min_dynamic_shared_memory分配的内存受操作系统上的huge_pages设置的影响(该操作系统支持该设置)，所以需要在系统启动时先进行分配，提高并行查询时的内存的预分配的效率问题。

还有vacuum_failsafe_age 和 vacuum_multixact_failsafe_age 两个参数，用来进来防止POSTGRESQL 数据库冻结炸弹产生的可能，尽力去避免，这也是需要仔细的去看的。

相关参考的信息：

https://www.mail-archive.com/pgsql-committers@lists.postgresql.org/msg24574.html

https://ottertune.com/blog/postgresql-knobs-list/