我一直在想，如果用一个运行的Postgres（即9.2.4）服务器sudo reboot ，可能会（或绝对会）导致数据丢失或其他问题（例如，无法在系统启动时重新启动服务器）。 或者， reboot发送正确的信号给进程，使其能够正常closures（包括例如允许事务完成等）。
如果您的服务器和硬件configuration正确，即使按下重置button，拔出电源线或触发内核恐慌，也不会丢失数据。 由于PostgreSQL的预写式日志logging，PostgreSQL是安全的 。
在这个评论中，唯一一个含糊其辞的人是“Zoredache”。
只有在以下情况下才会丢失数据
fsync=off来configurationPostgreSQL不是安全的。 UNLOGGED表，这些表不是安全的（在这种情况下，只会丢失未logging的表中的数据）。 fsync ，就像很多便宜的消费者SSD那样，在没有适当的备份功率的情况下，对caching进行回写caching; 几个月前，我在一篇博客文章中写了更多。
即使你使用的是廉价的固态硬盘，只有在系统实际上断电的情况下，通常也不会丢失突然重启的数据。 但是，我已经看到了一些能够在重置时重启磁盘的系统，而且如果使用便宜的SSD，这些系统将会丢失数据。
对于PostgreSQL来说，“干净的”closures几乎是可选的; 突然重新启动的唯一缺点是数据库可能需要更长的时间才能启动，因为在恢复过程中需要应用预写日志，而且（根据文档） UNLOGGED表将被截断。
即使在所谓的“干净”closures中，大多数init脚本也只会等待服务器closures的有限时间。 大多数初始化脚本使用“快速”closures模式，这将会中止当前的事务，拒绝新的会话，并快速但干净地closures服务器。 如果时间过长，closures，他们通常会超时，这要依靠PostgreSQL的崩溃安全。
如果要允许当前事务完成，则在closures系统之前需要手动执行“智能”closures，或者修改init脚本以使用它。 智能关机并不总是非常有用，因为长时间运行或放弃的连接可能会阻止整个服务器无限期closures，使其停在那里拒绝所有连接。 作为第一次尝试，您可以运行一分钟或快速关机之前。
碰撞安全不是没有采取备份的借口 – 并testing它们。
它应该优雅地closures它和所有正在运行的服务。 做一个备份和testing！
reboot是一个正常关机。 reboot -f / reboot --force是数据杀手。