PostgreSQL is a powerful, open source object-relational database system. It has more than 15 years of active development and a proven architecture that has earned it a strong reputation for reliability, data integrity, and correctness. It is fully ACID compliant, has full support for foreign keys, joins, views, triggers, and stored procedures (in multiple languages). It includes most SQL:2008 data types, including INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, and TIMESTAMP. It also supports storage of binary large objects, including pictures, sounds, or video. It has native programming interfaces for C/C++, Java, .Net, Perl, Python, Ruby, Tcl, ODBC, among others, and exceptional documentation.
An enterprise class database, PostgreSQL boasts sophisticated features such as Multi-Version Concurrency Control (MVCC), point in time recovery, tablespaces, asynchronous replication, nested transactions (savepoints), online/hot backups, a sophisticated query planner/optimizer, and write ahead logging for fault tolerance. It supports international character sets, multibyte character encodings, Unicode, and it is locale-aware for sorting, case-sensitivity, and formatting. It is highly scalable both in the sheer quantity of data it can manage and in the number of concurrent users it can accommodate. There are active PostgreSQL systems in production environments that manage in excess of 4 terabytes of data.
The pg_class.relfrozenxid value for TOAST tables was not correctly copied into the new installation during pg_upgrade. This could later result in pg_clog files being discarded while they were still needed to validate tuples in the TOAST tables, leading to “could not access status of transaction” failures.
This error poses a significant risk of data loss for installations that have been upgraded with pg_upgrade. This patch corrects the problem for future uses of pg_upgrade, but does not in itself cure the issue in installations that have been processed with a buggy version of pg_upgrade.
VACUUM would sometimes issue this warning in cases that are actually valid.
All retryable conflict errors now have an error code that indicates that a retry is possible. Also, session closure due to the database being dropped on the master is now reported as ERRCODE_DATABASE_DROPPED, rather than ERRCODE_ADMIN_SHUTDOWN, so that connection poolers can handle the situation correctly.
This affected recovery in non-hot-standby cases.
This prevents scenarios wherein the server could recurse infinitely while processing the composite type. While there are some possible uses for such a structure, they don’t seem compelling enough to justify the effort required to make sure it always works safely.
In some cases the cache loading code would acquire share lock on a system index before locking the index’s catalog. This could deadlock against processes trying to acquire exclusive locks in the other, more standard order.
This bug has been observed to result in intermittent “cannot extract system attribute from virtual tuple” failures while trying to do UPDATE RETURNING ctid. There is a very small probability of more serious errors, such as generating incorrect index entries for the updated tuple.
Formerly the DROP would go through, leading to “could not open relation with OID nnn” errors when the triggers were eventually fired.
“replication” is special in the database name column, but it was mistakenly also treated as special in the user name column.
This bug typically led to “cannot extract system attribute from virtual tuple” errors.
If the SSL mode is such that a root certificate file is not required, there is no need to fail. This change restores the behavior to what it was in pre-9.0 releases.
A typo caused the library to return NULL, rather than the PGconn structure containing the error message, to the application.
There was a hard-wired assumption that this system function was not available on MIPS hardware on these systems. Use a compile-time test instead, since more recent versions have it.