开源关系型数据库系统 PostgreSQL 17.2 免费版

一个强大的，开源的关系型数据库系统，拥有超过15年的积极发展。 PostgreSQL完全ACID兼容，全力支持外键，连接，视图，触发器和存储过程（多语言）。它包括大部分SQL92和SQL99中的数据包括整数，数字，布尔值，为char，varchar，日期，区间，和TIMESTAMP类型。

优点：

PostgreSQL 可以说是最富特色的自由数据库管理系统，甚至我们也可以说是最强大的自由软件数据库管理系统。事实上， PostgreSQL 的特性覆盖了 SQL-2/SQL-92 和 SQL-3/SQL-99，首先，它包括了可以说是目前世界上最丰富的数据类型的支持，其中有些数据类型可以说连商业数据库都不具备， 比如 IP 类型和几何类型等；其次，PostgreSQL 是全功能的自由软件数据库，很长时间以来，PostgreSQL 是唯一支持事务、子查询、多版本并行控制系统、数据完整性检查等特性的唯一的一种自由软件的数据库管理系统。直到最近才有 Inprise 的 InterBase 以及 SAP 等厂商将其原先专有软件开放为自由软件之后才打破了这个唯一。最后，PostgreSQL拥有一支非常活跃的开发队伍，目前的提交人员已经超过三十人， 而且在许多黑客的努力下，PostgreSQL 的质量日益提高，也从另外一个侧面上增加了人们使用 PostgreSQL 的信心，毕竟数据库管理系统不能象桌面操作系统那样 一天宕一次还让人觉得挺满意 :-P。

从技术角度来讲，PostgreSQL 采用的是比较经典的 C/S （client/server）结构，也就是一个客户端对应一个服务器端守护进程的模式， 这个守护进程分析客户端来的查询请求，生成规划树，进行数据检索并最终把结果格式化输出后返回给客户端。为了便于客户端的程序的编写， 由数据库服务器提供了统一的客户端 C 接口。而不同的客户端接口都是源自这个 C 接口，比如 ODBC，JDBC，Python，Perl ，Tcl，C/C++，ESQL 等， 同时也要指出的是，PostgreSQL 对接口的支持也是非常丰富的，几乎支持所有类型的数据库客户端接口。这一点也可以说是 PostgreSQL 一大优点。

缺点：

说完优点，不能不说几句缺点，不能因为是自由软件而偏袒 PostgreSQL，从 Postgres 开始，PostgreSQL 就经受了多次变化。

首先，早期的 PostgreSQL 继承了几乎所有 Ingres, Postgres, Postgres95 的问题：过于学院味，因为首先它的目的是数据库研究，因此不论在稳定性， 性能还是使用方便方面，长期以来一直没有得到重视，直到 PostgreSQL 项目开始以后，情况才越来越好，目前，PostgreSQL 已经完全可以胜任任何中上规模范围内的应用范围的业务。目前有报道的生产数据库的大小已经有 TB 级的数据量，已经逼近 32 位计算的极限。 不过学院味也给 PostgreSQL 带来一个意想不到的好处：大概因为各大学的软硬件环境差异太大的缘故，它是目前支持平台最多的数据库管理系统的一种， 所支持的平台多达十几种，包括不同的系统，不同的硬件体系。至今，它仍然保持着支持平台最多的数据库管理系统的称号。

其次，PostgreSQL 的确还欠缺一些比较高端的数据库管理系统需要的特性，比如联机热备份，数据库集群，更优良的管理工具和更加自动化的系统优化功能 等提高数据库性能的机制等。

但是，话说回来，PostgreSQL 拥有极其强大的扩展能力，你可以很容易地扩展数据类型，内部函数，聚集，操作符等等，而且，别忘了，你拥有所有的源程序， 理论上你可以做任何你可以做的事情。因此，很多缺点，在转瞬之间就会消失也是很正常的。

总而言之，PostgreSQL的特性已经完全可以满足绝大部分用户的需要，而且其质量和特性仍然在日新月异地进步着，所以， 我们有理由相信在不远的将来，PostgreSQL 肯定能够成为一种优秀的，自由的，商业数据库的替代产品。

功能特点

PostgreSQL支持大部分 SQL标准并且提供了许多其他现代特性：复杂查询、外键、触发器、视图、事务完整性、MVCC。同样，PostgreSQL 可以用许多方法扩展，比如， 通过增加新的数据类型、函数、操作符、聚集函数、索引方法、过程语言。并且，因为许可证的灵活，任何人都可以以任何目的免费使用、修改、和分发 PostgreSQL，不管是私用、商用、还是学术研究使用。

图形安装程序PostgreSQL包括PostgreSQL服务器，pgAdmin III;一个图形化工具，用于管理和发展您的数据库，StackBuilder;可用于下载和安装额外的PostgreSQL的应用程序和驱动程序的软件包管理器。

安装程序被设计成尽可能简单和最快的方式启动，与PostgreSQL在Windows上运行。

从EnterpriseDB下载安装程序的所有受支持版本。

高级用户还可以下载的二进制文件的zip归档文件，无需安装程序。这是不建议正常安装，它的目的是为客户谁希望包括PostgreSQL作为另一个应用程序的安装程序的一部分用户。

请安装VC2005 运行库

PostgreSQL 9.1.3.1 win 64位版：http://get.enterprisedb.com/postgresql/postgresql-9.1.3-1-windows-x64-binaries.zip

其它系统下载：http://www.enterprisedb.com/products-services-training/pgbindownload

更新日志

E.1。版本9.6.9

发布日期：2018-05-10

此版本包含来自9.6.8的各种修补程序。有关9.6主要版本中的新功能的信息，请参阅第E.10节。
E.1.1。迁移到版本9.6.9

运行9.6.X的用户不需要转储/恢复。

但是，如果您使用adminpack扩展名，则应根据下面的第一个更新日志条目对其进行更新。

另外，如果下面第二个和第三个更改日志条目中提到的函数标记错误会影响到您，您将需要采取措施来纠正您的数据库目录。

另外，如果您从9.6.8之前的版本升级，请参见部分E.2。
E.1.2。变化

    从contrib / adminpack的pg_logfile_rotate（）函数中删除公共执行特权（Stephen Frost）

    pg_logfile_rotate（）是核心函数pg_rotate_logfile（）的弃用包装。当该函数被改为依赖SQL访问控制权限而不是硬编码的超级用户检查时，pg_logfile_rotate（）也应该被更新，但是错过了这个需求。因此，如果安装了adminpack，任何用户都可以请求日志文件轮换，从而产生轻微的安全问题。

    安装此更新后，管理员应通过在安装了adminpack的每个数据库中执行ALTER EXTENSION adminpack UPDATE更新adminpack。 （CVE-2018年至1115年）

    修正一些内置功能上不正确的波动标记（Thomas Munro，Tom Lane）

    函数query_to_xml，cursor_to_xml，cursor_to_xmlschema，query_to_xmlschema和query_to_xml_and_xmlschema应该标记为volatile，因为它们执行用户提供的可能包含易失性操作的查询。它们不是，导致不正确查询优化的风险。已通过更正初始目录数据修复了新安装，但现有安装将继续包含不正确的标记。实际使用这些函数似乎没有什么危险，但是如果遇到问题，可以通过手动更新这些函数的pg_proc条目来修复，例如ALTER FUNCTION pg_catalog.query_to_xml（text，boolean，boolean，text）VOLATILE。 （请注意，这需要在安装的每个数据库中完成。）另一个选项是将数据库升级到包含更正的初始数据的版本。

    在一些内置功能上修复不正确的平行安全标记（Thomas Munro，Tom Lane）

    功能brin_summarize_new_values，gin_clean_pending_list，cursor_to_xml，cursor_to_xmlschema，ts_rewrite，ts_stat和binary_upgrade_create_empty_extension应标明平行不安全;有些是因为他们直接执行数据库修改，还有一些是因为他们执行用户提供的查询，可能会这样做。它们被标记为并行限制，导致出现意外查询错误的风险。已通过更正初始目录数据修复了新安装，但现有安装将继续包含不正确的标记。除非启用force_parallel_mode，否则实际使用这些函数似乎不会造成什么危害。如果遇到问题，可以通过手动更新这些函数的pg_proc条目来修复，例如ALTER FUNCTION pg_catalog.brin_summarize_new_values（regclass）PARALLEL UNSAFE。 （请注意，这需要在安装的每个数据库中完成。）另一个选项是将数据库升级到包含更正的初始数据的版本。

    避免重新使用TOAST值OID匹配已经死亡但尚未抽真空的TOAST条目（Pavan Deolasee）

    一旦OID计数器已经打包，可以分配一个TOAST值，其OID与TOAST表中先前删除的条目相匹配。如果该条目还没有被吸走，这会导致“意外的组块号0（预期1）为烤面包值nnnnn”错误，这将持续到VACUUM删除死的条目。通过在创建新的TOAST条目时不选择这些OID进行修复。

    更改ANALYZE用于更新pg_class.reltuples的算法（David Gould）

    以前，ANALYZE实际上未扫描的页面被假定为保留其旧元组密度。在ANALYZE仅抽取一小部分页面的大型表格中，这意味着整体元组密度估计不会有太大变化，因此无论什么元素是什么，reltuples都会与表格物理大小（更新）的变化几乎成比例地变化实际上发生在桌子上。据观察，这导致reltuples变得比现实大得多，以至于有效地关闭了自动清理。为了解决这个问题，假设ANALYZE的样本是一张统计无偏的样本（应该是这样），并且只是将这些页面内观察到的密度外推到整个表格。

    避免在SERIALIZABLE或REPEATABLE READ事务隔离下运行的并发CREATE INDEX CONCURRENTLY命令中的死锁（Tom Lane）

    修复REFRESH MATERIALIZED VIEW CONCU缓慢执行的可能性