PostgreSQL有哪些不能做的foolish操作

这篇文章主要介绍“PostgreSQL有哪些不能做的foolish操作”，在日常操作中，相信很多人在PostgreSQL有哪些不能做的foolish操作问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”PostgreSQL有哪些不能做的foolish操作”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

工作时间长了，可能就会总结出来一些东西，千万不能做，做了会让你后悔莫及。

先说一些我们的前提

1 拥有数据库的所有权限

2 不能通过故意的方式来毁掉一个数据库 例如 rm -rf

那我们就开始列一列那些操作会让你追悔莫及

1 删除pg_class

对系统表不敬，大部分数据库都有自己的系统表，而这些表中存储着非常重要的信息，postgresql 中的 pg_catalog 中的pg_class 算是一个核心的表。

我们看看清空他怎么样

truncate table pg_catalog.pg_class;

即使你拥有初始的最大的权限，PG 的核心表，你也是没有权利去删除他的。

但如果你换了一种方法

然后你退出，在psql 连入到postgresql中你会发现，不OK了

pg_class 是PG中最重要的系统表之一，其中存储着所有的系统的表中的object 的信息，OID信息，将他delete 后，基本上pg 无法在提供正常的服务，甚至是连入到PG中。

2 对系统文件的误删除

在很多数据库中都有关键的控制文件，清理了配置控制文件的后果也是可以让你记忆深刻。下面我们删除PG中的 pg_control

此时我们建立一个新的数据库，就失败了

具体这样的操作的失败的原因，是检查点的位置保存在文件pg_control中。因此，在恢复开始时，服务器首先读取pg_control，读取检查点记录，通过从检查点记录中指定的日志位置向前扫描来执行重做操作。所以在删除了pg_control后，首先检查点的checkpoint的工作就无法进行下去了。整体的数据库系统就无法继续工作，导致系统崩溃。

那如果删除了pg_control 后还能让PG重新启动吗？，可以但结果可能并不是你要的，即使你使用pg_resetwal 恢复了pg_control 数据库可以启动后，但很可能你得到得的结果是

所以pg_control 是你不能丢失的控制文件。

3  清理你的模板数据库

模板数据库，意思即使你创建其他数据库的基础，例如里面已经加载的扩展信息，或者你往里面添加的任何数据库，表，或者存储过程  ，触发器等元素，都会在你 create database 后从模板数据库中带过来。

当然有人说，你删不掉 template1 template0 两个数据库，因为删除的时候回报，他们是模板数据库，不能删除。

上图就是删除了模板数据库，然后在创建数据库的时候，就.......  failed.

4  设置权限的时候 pg_hba.conf, 如下图设置

举例我们设置一个账号

则最低的保障是需要系统在非主机登陆时，提供账号密码的验证，由于上面pg_hba的设置，导致任何人在任何时候，不使用任何密码都可以登陆到数据库中。

数据库的安全荡然无存。

5  写 CTE 时使用recursive 时进行类似死循环的递归活动，造成语句最后失败，并造成系统资源异常消耗。

这样的语句会造成 

1系统资源严重消耗

2 系统的TEMP 库疯狂的使用，很可能会造成你的temp 库占用大量的磁盘空间

3 造成客户端连接被 KILL 

到此，关于“PostgreSQL有哪些不能做的foolish操作”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！