Runs stored procedures in more than a dozen programming languages, including Java, etc. Permits the database designer to create rules which identify specific operations for a given table or view. Offers the ability to database designers to derive new tables from other tables.
PostgreSQL is an object-relational database management system (ORDBMS) created originally at University of California. Its SQL implementation strongly conforms to the ANSI-SQL 92/99 standards supporting it. It has full support for triggers, views, queries, stored procedures, joins, multiple languages, among others. Some features of this Database include multi version concurrency control (MVCC), point in time recovery, tablespaces, replication (asynchronous), nested transaction, online backups, fault tolerance and many other sophisticated features to provide data integrity.
Some of the allowed maximum values offer big possibilities for huge database systems: unlimited maximum Database size, rows per table and indexes per table, or 32TB maximum for a table's size. The system supports SSL and IPv6 protocols. It also supports many data types, like arrays and XML among many others. Third party contributions are also important for this ORDBMS, because many of the tools to develop, access or use this database exist only because of them. The system also supports GIS (Geographical Information System) data and it can be used for mapping and localization purposes.
The current release includes many fixes reported by its contributors and some new features like full text search integration, support for SQL/XML standard, includes some new data types (enumerated, arrays of composite types, XML, Universal Unique Identifier), it improves logging and statics collections, and much more.
Its installation process is very easy to perform; moreover, some third party utilities and programs are included depending your requests or needs. The Stack Builder utility manages all the installations. Its GUI depends on how would you like to view your data; a nice program to view and manage your databases is pgAdmin III. Its documentation is very complete and detailed; you can find a lot of documentation in its website and included with the program. PostgreSQL works in Linux, UNIX and Windows platforms.
v9.6.11.18310 [May 19, 2016]
Changes
Fix WAL-logging of truncation of relation free space maps and visibility maps (Pavan Deolasee, Heikki Linnakangas)
It was possible for these files to not be correctly restored during crash recovery, or to be written incorrectly on a standby server. Bogus entries in a free space map could lead to attempts to access pages that have been truncated away from the relation itself, typically producing errors like "could not read block XXX: read only 0 of 8192 bytes". Checksum failures in the visibility map are also possible, if checksumming is enabled.
Procedures for determining whether there is a problem and repairing it if so are discussed at https://wiki.postgresql.org/wiki/Free_Space_Map_Problems.
Fix possible data corruption when pg_upgrade rewrites a relation visibility map into 9.6 format (Tom Lane)
On big-endian machines, bytes of the new visibility map were written in the wrong order, leading to a completely incorrect map. On Windows, the old map was read using text mode, leading to incorrect results if the map happened to contain consecutive bytes that matched a carriage return/line feed sequence. The latter error would almost always lead to a pg_upgrade failure due to the map file appearing to be the wrong length.
If you are using a big-endian machine (many non-Intel architectures are big-endian) and have used pg_upgrade to upgrade from a pre-9.6 release, you should assume that all visibility maps are incorrect and need to be regenerated. It is sufficient to truncate each relation's visibility map with contrib/pg_visibility's pg_truncate_visibility_map() function. For more information see https://wiki.postgresql.org/wiki/Visibility_Map_Problems.
Don't throw serialization errors for self-conflicting insertions in INSERT ... ON CONFLICT (Thomas Munro, Peter Geoghegan)
Fix use-after-free hazard in execution of aggregate functions using DISTINCT (Peter Geoghegan)
This could lead to a crash or incorrect query results.
Fix incorrect handling of polymorphic aggregates used as window functions (Tom Lane)
The aggregate's transition function was told that its first argument and result were of the aggregate's output type, rather than the state type. This led to errors or crashes with polymorphic transition functions.
Fix COPY with a column name list from a table that has row-level security enabled (Adam Brightwell)
Fix EXPLAIN to emit valid XML when track_io_timing is on (Markus Winand)
Previously the XML output-format option produced syntactically invalid tags such as . That is now rendered as .
Fix statistics update for TRUNCATE in a prepared transaction (Stas Kelvich)
Fix bugs in merging inherited CHECK constraints while creating or altering a table (Tom Lane, Amit Langote)
Allow identical CHECK constraints to be added to a parent and child table in either order. Prevent merging of a valid constraint from the parent table with a NOT VALID constraint on the child. Likewise, prevent merging of a NO INHERIT child constraint with an inherited constraint.
Show a sensible value in pg_settings.unit for min_wal_size and max_wal_size (Tom Lane)
Fix replacement of array elements in jsonb_set() (Tom Lane)
If the target is an existing JSON array element, it got deleted instead of being replaced with a new value.
Avoid very-low-probability data corruption due to testing tuple visibility without holding buffer lock (Thomas Munro, Peter Geoghegan, Tom Lane)
Preserve commit timestamps across server restart (Julien Rouhaud, Craig Ringer)
With track_commit_timestamp turned on, old commit timestamps became inaccessible after a clean server restart.
Fix logical WAL decoding to work properly when a subtransaction's WAL output is large enough to spill to disk (Andres Freund)
Fix dangling-pointer problem in logical WAL decoding (Stas Kelvich)
Round shared-memory allocation request to a multiple of the actual huge page size when attempting to use huge pages on Linux (Tom Lane)
This avoids possible failures during munmap() on systems with atypical default huge page sizes. Except in crash-recovery cases, there were no ill effects other than a log message.
Don't try to share SSL contexts across multiple connections in libpq (Heikki Linnakangas)
This led to assorted corner-case bugs, particularly when trying to use different SSL parameters for different connections.
Avoid corner-case memory leak in libpq (Tom Lane)
The reported problem involved leaking an error report during PQreset(), but there might be related cases.
Feature-rich relational database known for its high performance and excellent concurrency
Mall Creeps
