PostgreSQL 运维的难与“难” --上海PG大会主题记录

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2680人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6群均已爆满，新人进7群400+，8群，开9群)

2025年1月4日参加了中国PostgreSQL数据库生态大会，以下为台上的20分钟记录。

此次的话题是，PostgreSQL运维的难与“难”，我们来讨论讨论运维中，我们虽然掌握的很多的PostgreSQL的运维知识，为什么还是有九九81“难”。

本次的话题将分为四个部分 

1  简单的介绍本次的主题 

2  通过三个小的运维实例故事来切入主题 

3  在切入主题后，我们反思为什么知识都会，依然是还是“不会” 

4  最后运维中我们要面对什么具体的问题与时代的变化

在PostgreSQL的运维工作中，难题比比皆是。是我们技术不行吗？还是我们技术没有掌握的牢固。这里要表达的观点是

1 技术在部分运维的场合中，并不是你解决问题的关键。

2 数据库也有先来后到，后来的数据库会遭受更多的责难和不理解，让运维的工作难，难上加难。

3 当前客户的习惯从可以忍耐一些数据库的“异类问题”，到耐心越来越低，不行就换的思维开始占领了数据库市场。

下面我们通过三个小故事来阐述以上的论点。三个故事分别是

1 该不该说

2 该不该做

3 牵着不走

我们先说第一个故事，该不该“说”，PG有一个历史性的问题，有登录权限的账号，在没有实际的创建表或其他如视图，函数，存储过程等情况下，可以在任意的逻辑库中建立，表、视图、函数、存储过程、序列等等。

不少其他的数据库专业的DBA，对此非常的不理解，认为这和他们的数据库的操作方案非常的不同，有安全的风险问题。

可从多年的PostgreSQL的运维工作中，并未发现有因为此问题导致的产生“实际”生产安全的问题。

部分“大聪明”，如同我们故事里面的这个DBA，知道这个问题，新官上任三把火。将这个问题搞得惊天动地，但做好做，改可是不好改，这牵着到数据库，程序配置等多方面的配合改造。尤其已经运维很长一段时间的基于PG的应用程序。

而在大肆宣扬此问题后，必然会有“好事”者洞察的这个问题，并加以利用，不说还好，说了“好事”者到会利用此问题进行一些非正常的操作。

此故事为“该不该说”。

可我们完全不应该说吗？ 也不是我们要辨别的说，看业务如何利用数据库，看当前的公司在使用数据库方面的层次和水平，有的放