https://wiki.postgresql.org/api.php?action=feedcontributions&user=Aglio&feedformat=atomPostgreSQL wiki - User contributions [en]2024-03-28T23:46:45ZUser contributionsMediaWiki 1.35.13https://wiki.postgresql.org/index.php?title=SCALE16x&diff=31575SCALE16x2018-03-09T19:59:05Z<p>Aglio: /* Thursday, Mar 8 */</p>
<hr />
<div>We had a two-day, two-track Postgres event at SoCal Linux Expo (SCaLE) March 8 & 9, 2018.<br />
<br />
Conference website: [http://www.socallinuxexpo.org/scale/16x SCaLE16x]<br />
<br />
Events shown for placeholding purposes. See the "Editing help" for instructions on how to add a link to your slides.<br />
<br />
== Thursday, Mar 8 ==<br />
* [http://slides.keithf4.com/pg_admin_training_centos PostgreSQL Administration Training] - Keith Fiske<br />
* [https://github.com/jberkus/annotated.conf Postgres GUCS]: A Three-Hour Tour - Josh Berkus<br />
* Exploring Common Table Expressions and Window Functions - Bruce Momjian<br />
<br />
== Friday, Mar 9 ==<br />
* PostgreSQL Partitioning - Robert Treat<br />
* [http://sarahconway.com/slides/scale2018-postgres-operator.pdf PostgreSQL Operator] - Sarah Conway<br />
* Monitoring PostgreSQL 101 - Jason Yee<br />
* Advanced SQL - Stephen Frost<br />
* Tuning PostgreSQL for High Write Workloads - Grant McAlister<br />
* PostgreSQL and REST API's The Easy Way - Charles Finley<br />
* Hidden Talents of the PostgreSQL JDBC Driver - Dave Cramer<br />
* The Many Faces of PostgreSQL Replication - Phil Vacca<br />
* [http://anarazel.de/talks/scale16x-2018-03-09/jit-and-other-efficiency.pdf Improving Postgres' Efficiency using JIT and other techniques] - Andres Freund<br />
* Securing Your Data on PostgreSQL - Payal Singh<br />
* Automated Failover With PostgreSQL - Scott Mead<br />
* TimescaleDB: Re-engineering PostgreSQL as a time-series database - David Kohn</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30621New in postgres 102017-07-20T05:48:41Z<p>Aglio: /* Renaming of "xlog" to "wal" Globally (and location/lsn) */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
In 10, partitioning tables is now an attribute of the table:<br />
<br />
CREATE TABLE table_name ( ... )<br />
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) }<br />
<br />
CREATE TABLE table_name<br />
PARTITION OF parent_table [ (<br />
) ] FOR VALUES partition_bound_spec<br />
'''<br />
Example'''<br />
<br />
Before:<br />
CREATE TABLE padre (<br />
id serial,<br />
pais integer,<br />
fch_creado timestamptz not null<br />
);<br />
<br />
CREATE TABLE hija_2017 (<br />
CONSTRAINT pk_2017 PRIMARY KEY (id),<br />
CONSTRAINT ck_2017 CHECK (fch_creado < DATE '2015-01-01' )<br />
) INHERITS (padre);<br />
CREATE INDEX idx_2017 ON hija_2017 (fch_creado);<br />
<br />
Today:<br />
CREATE TABLE padre (<br />
id serial not null,<br />
nombre text not null,<br />
fch_creado timestamptz not null<br />
)<br />
PARTITION BY RANGE ( id );<br />
<br />
CREATE TABLE hijo_0<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (unbounded) to (10);<br />
<br />
CREATE TABLE hijo_1<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (10) to (unbounded);<br />
<br />
This means that users no longer need to create triggers for routing data; it's all handled by the system.<br />
<br />
'''Another Example:'''<br />
<br />
For example, we might decide to partition the `book_history` table, probably a good idea since that table is liable to accumulate data forever. Since it's a log table, we'll range partition it, with one partition per month.<br />
<br />
First, we create a "master" partition table, which will hold no data but forms a template for the rest of the partitions:<br />
<br />
<br />
libdata=# CREATE TABLE book_history (<br />
book_id INTEGER NOT NULL,<br />
status BOOK_STATUS NOT NULL,<br />
period TSTZRANGE NOT NULL )<br />
PARTITION BY RANGE ( lower (period) );<br />
<br />
<br />
Then we create several partitions, one per month:<br />
<br />
<br />
libdata=# CREATE TABLE book_history_2016_09<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-09-01 00:00:00') TO ('2016-10-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_08<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-08-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_07<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-07-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
ERROR: partition "book_history_2016_07" would overlap partition "book_history_2016_08"<br />
<br />
<br />
As you can see, the system even prevents accidental overlap. New rows will automatically be stored in the correct partition, and SELECT queries will search the appropriate partitions.<br />
<br />
<br />
<br />
* [https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 commit]<br />
* [https://www.postgresql.org/docs/devel/static/ddl-partitioning.html#ddl-partitioning-declarative Documentation]<br />
* [https://www.keithf4.com/postgresql-10-built-in-partitioning/ Built-in Partitioning]<br />
<br />
=== Additional Parallelism ===<br />
<br />
Some additional plan nodes can be executed in parallel, particularly Index Scans.<br />
<br />
'''Example:'''<br />
<br />
For example, if we wanted to search financial transaction history by an indexed column, I can now execute it in one-quarter the time by using four parallel workers:<br />
<br />
accounts=# \timing<br />
Timing is on.<br />
accounts=# select bid, count(*) from account_history<br />
where delta > 1000 group by bid;<br />
...<br />
Time: 324.903 ms<br />
<br />
accounts=# set max_parallel_workers_per_gather=4;<br />
SET<br />
Time: 0.822 ms<br />
accounts=# select bid, count(*) from account_history<br />
where delta > 1000 group by bid;<br />
...<br />
Time: 72.864 ms<br />
<br />
(this assumes an index on bid, delta)<br />
<br />
Links:<br />
<br />
* [http://rhaas.blogspot.com.ar/2017/03/parallel-query-v2.html Parallel Query v2]<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
example:<br />
<br />
Suppose I decide I want to replicate just the fines and loans tables from my public library database to the billing system so that they can process amounts owed. I would create a publication from those two tables with this command:<br />
<br />
<br />
libdata=# CREATE PUBLICATION financials FOR TABLE ONLY loans, ONLY fines;<br />
CREATE PUBLICATION<br />
<br />
<br />
Then, in the billing database, I would create two tables that looked identical to the tables I'm replicating, and have the same names. They can have additional columns and a few other differences. Particularly, since I'm not copying the patrons or books tables, I'll want to drop some foreign keys that they origin database has. I also need to create any special data types or other database artifacts required for those tables. Often the easiest way to do this is selective use of the `pg_dump` and `pg_restore` backup utilities:<br />
<br />
<br />
origin# pg_dump libdata -Fc -f /netshare/libdata.dump<br />
<br />
replica# pg_restore -d libdata -s -t loans -t fines /netshare/libdata.dump<br />
<br />
<br />
Following that, I can start a Subscription to those two tables:<br />
<br />
<br />
libdata=# CREATE SUBSCRIPTION financials<br />
CONNECTION 'dbname=libdata user=postgres host=172.17.0.2'<br />
PUBLICATION financials;<br />
NOTICE: synchronized table states<br />
NOTICE: created replication slot "financials" on publisher<br />
CREATE SUBSCRIPTION<br />
<br />
<br />
This will first copy a snapshot of the data currently in the tables, and then start catching up from the transaction log. Once it's caught up, you can check status in pg_stat_subscription:<br />
<br />
<br />
libdata=# select * from pg_stat_subscription;<br />
-[ RECORD 1 ]---------+---------------------<br />
subid | 16475<br />
subname | financials<br />
pid | 167<br />
relid |<br />
received_lsn | 0/1FBEAF0<br />
last_msg_send_time | 2017-06-07 00:59:44<br />
last_msg_receipt_time | 2017-06-07 00:59:44<br />
latest_end_lsn | 0/1FBEAF0<br />
latest_end_time | 2017-06-07 00:59:44<br />
<br />
<br />
blogs:<br />
<br />
* [https://blog.2ndquadrant.com/logical-replication-postgresql-10/ Logical Replication in PostgreSQL 10]<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
While version 9.6 introduced quorum based synchronous replication, <br />
<br />
synchronous_commit = 'remote_apply'<br />
<br />
version 10 improves the synchronous_standby_names GUC by adding the FIRST and ANY keywords:<br />
<br />
synchronous_standby_names = ANY 2(node1,node2,node3);<br />
synchronous_standby_names = FIRST 2(node1,node2);<br />
<br />
FIRST was the previous behaviour, and the nodes priority is following the list order in order to get a quorum. ANY now means that any node in the list is now able to provide the required quorum. This will give extra flexibility to complex replication setups.<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
[http://paquier.xyz/postgresql-2/postgres-10-libpq-read-write/ Implement failover on libpq connect level]<br />
<br />
=== Traceable Commit ===<br />
<br />
[https://blog.2ndquadrant.com/traceable-commit-postgresql-10/ Traceable commit for PostgreSQL 10]<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Identity Columns ===<br />
<br />
[https://blog.2ndquadrant.com/postgresql-10-identity-columns/ PostgreSQL 10 identity columns explained]<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
You can now create Full Text Indexes on JSON and JSONB columns.<br />
<br />
This involves converting the JSONB field to a `tsvector`, then creating an specific language full-text index on it:<br />
<br />
<br />
libdata=# CREATE INDEX bookdata_fts ON bookdata<br />
USING gin (( to_tsvector('english',bookdata) ));<br />
CREATE INDEX<br />
<br />
Once that's set up, you can do full-text searching against all of the values in your JSON documents:<br />
<br />
libdata=# SELECT bookdata -> 'title'<br />
FROM bookdata<br />
WHERE to_tsvector('english',bookdata) @@ to_tsquery('duke'); <br />
------------------------------------------<br />
"The Tattooed Duke"<br />
"She Tempts the Duke"<br />
"The Duke Is Mine"<br />
"What I Did For a Duke"<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Cross-column Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
[https://blog.2ndquadrant.com/pg-phriday-crazy-correlated-column-crusade/ PG Phriday: Crazy Correlated Column Crusade]<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===<br />
<br />
[https://blog.2ndquadrant.com/icu-support-postgresql-10/ More robust collations with ICU support in PostgreSQL 10]<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation. Users should specifically test for the incompatibilities before upgrading in production.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally (and location/lsn) ===<br />
<br />
In order to avoid confusion leading to data loss, everywhere we previously used the abbreviation "xlog" to refer to the transaction log, including directories, functions, and parameters for executables, we now use "wal". Similarly, the word "location" in function names, where used to refer to transaction log location, has been replaced with "lsn".<br />
<br />
This will require many users to reprogram custom backup and transaction log management scripts, as well as monitoring replication.<br />
<br />
Two directories have been renamed:<br />
<br />
{|<br />
! 9.6 Directory !! 10 Directory<br />
|-<br />
| pg_xlog || pg_wal<br />
|-<br />
| pg_clog || pg_xact<br />
|}<br />
<br />
Additionally, depending on where your installation packages come from, the default activity log location may have been renamed from "pg_log" to just "log".<br />
<br />
Many administrative functions have been renamed to use "wal" and "lsn":<br />
<br />
{|<br />
! 9.6 Function Name !! 10 Function Name <br />
|-<br />
| pg_current_xlog_flush_location || pg_current_wal_flush_lsn<br />
|-<br />
| pg_current_xlog_insert_location || pg_current_wal_insert_lsn<br />
|-<br />
| pg_current_xlog_location || pg_current_wal_lsn<br />
|-<br />
| pg_is_xlog_replay_paused || pg_is_wal_replay_paused<br />
|-<br />
| pg_last_xlog_receive_location || pg_last_wal_receive_lsn<br />
|-<br />
| pg_last_xlog_replay_location || pg_last_wal_replay_lsn<br />
|-<br />
| pg_switch_xlog || pg_switch_wal<br />
|-<br />
| pg_xlog_location_diff || pg_wal_lsn_diff<br />
|-<br />
| pg_xlog_replay_pause || pg_wal_replay_pause<br />
|-<br />
| pg_xlog_replay_resume || pg_wal_replay_resume<br />
|-<br />
| pg_xlogfile_name || pg_walfile_name<br />
|-<br />
| pg_xlogfile_name_offset || pg_walfile_name_offset<br />
|}<br />
<br />
Some system views and functions have had attribute renames:<br />
* pg_stat_replication:<br />
** write_location -> write_lsn<br />
** sent_location -> sent_lsn<br />
** flush_location -> flush_lsn<br />
** replay_location -> replay_lsn<br />
* pg_create_logical_replication_slot: wal_position -> lsn<br />
* pg_create_physical_replication_slot: wal_position -> lsn<br />
* pg_logical_slot_get_changes: location -> lsn<br />
* pg_logical_slot_peek_changes: location -> lsn<br />
<br />
Several command-line executables have had parameters renamed:<br />
<br />
* pg_receivexlog has been renamed to pg_receivewal.<br />
* pg_resetxlog has been renamed to pg_resetwal.<br />
* pg_xlogdump has been renamed to pg_waldump.<br />
* initdb and pg_basebackup have a --waldir option rather than --xlogdir.<br />
* pg_basebackup now has --wal-method rather than --xlog-method.<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.0 ===<br />
<br />
Databases running on PostgreSQL version 7.4 and earlier will not be supported by 10's pg_dump or pg_dumpall. If you need to convert a database that old, use version 9.6 or earlier to upgrade it in two stages.</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30613New in postgres 102017-07-19T16:49:30Z<p>Aglio: /* Renaming of "xlog" to "wal" Globally (and location/lsn) */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
In 10, partitioning tables is now an attribute of the table:<br />
<br />
CREATE TABLE table_name ( ... )<br />
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) }<br />
<br />
CREATE TABLE table_name<br />
PARTITION OF parent_table [ (<br />
) ] FOR VALUES partition_bound_spec<br />
'''<br />
Example'''<br />
<br />
Before:<br />
CREATE TABLE padre (<br />
id serial,<br />
pais integer,<br />
fch_creado timestamptz not null<br />
);<br />
<br />
CREATE TABLE hija_2017 (<br />
CONSTRAINT pk_2017 PRIMARY KEY (id),<br />
CONSTRAINT ck_2017 CHECK (fch_creado < DATE '2015-01-01' )<br />
) INHERITS (padre);<br />
CREATE INDEX idx_2017 ON hija_2017 (fch_creado);<br />
<br />
Today:<br />
CREATE TABLE padre (<br />
id serial not null,<br />
nombre text not null,<br />
fch_creado timestamptz not null<br />
)<br />
PARTITION BY RANGE ( id );<br />
<br />
CREATE TABLE hijo_0<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (unbounded) to (10);<br />
<br />
CREATE TABLE hijo_1<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (10) to (unbounded);<br />
<br />
This means that users no longer need to create triggers for routing data; it's all handled by the system.<br />
<br />
'''Another Example:'''<br />
<br />
For example, we might decide to partition the `book_history` table, probably a good idea since that table is liable to accumulate data forever. Since it's a log table, we'll range partition it, with one partition per month.<br />
<br />
First, we create a "master" partition table, which will hold no data but forms a template for the rest of the partitions:<br />
<br />
<br />
libdata=# CREATE TABLE book_history (<br />
book_id INTEGER NOT NULL,<br />
status BOOK_STATUS NOT NULL,<br />
period TSTZRANGE NOT NULL )<br />
PARTITION BY RANGE ( lower (period) );<br />
<br />
<br />
Then we create several partitions, one per month:<br />
<br />
<br />
libdata=# CREATE TABLE book_history_2016_09<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-09-01 00:00:00') TO ('2016-10-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_08<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-08-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_07<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-07-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
ERROR: partition "book_history_2016_07" would overlap partition "book_history_2016_08"<br />
<br />
<br />
As you can see, the system even prevents accidental overlap. New rows will automatically be stored in the correct partition, and SELECT queries will search the appropriate partitions.<br />
<br />
<br />
<br />
* [https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 commit]<br />
* [https://www.postgresql.org/docs/devel/static/ddl-partitioning.html#ddl-partitioning-declarative Documentation]<br />
* [https://www.keithf4.com/postgresql-10-built-in-partitioning/ Built-in Partitioning]<br />
<br />
=== Additional Parallelism ===<br />
<br />
Some additional plan nodes can be executed in parallel, particularly Index Scans.<br />
<br />
'''Example:'''<br />
<br />
For example, if we wanted to search financial transaction history by an indexed column, I can now execute it in one-quarter the time by using four parallel workers:<br />
<br />
accounts=# \timing<br />
Timing is on.<br />
accounts=# select bid, count(*) from account_history<br />
where delta > 1000 group by bid;<br />
...<br />
Time: 324.903 ms<br />
<br />
accounts=# set max_parallel_workers_per_gather=4;<br />
SET<br />
Time: 0.822 ms<br />
accounts=# select bid, count(*) from account_history<br />
where delta > 1000 group by bid;<br />
...<br />
Time: 72.864 ms<br />
<br />
(this assumes an index on bid, delta)<br />
<br />
Links:<br />
<br />
* [http://rhaas.blogspot.com.ar/2017/03/parallel-query-v2.html Parallel Query v2]<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
example:<br />
<br />
Suppose I decide I want to replicate just the fines and loans tables from my public library database to the billing system so that they can process amounts owed. I would create a publication from those two tables with this command:<br />
<br />
<br />
libdata=# CREATE PUBLICATION financials FOR TABLE ONLY loans, ONLY fines;<br />
CREATE PUBLICATION<br />
<br />
<br />
Then, in the billing database, I would create two tables that looked identical to the tables I'm replicating, and have the same names. They can have additional columns and a few other differences. Particularly, since I'm not copying the patrons or books tables, I'll want to drop some foreign keys that they origin database has. I also need to create any special data types or other database artifacts required for those tables. Often the easiest way to do this is selective use of the `pg_dump` and `pg_restore` backup utilities:<br />
<br />
<br />
origin# pg_dump libdata -Fc -f /netshare/libdata.dump<br />
<br />
replica# pg_restore -d libdata -s -t loans -t fines /netshare/libdata.dump<br />
<br />
<br />
Following that, I can start a Subscription to those two tables:<br />
<br />
<br />
libdata=# CREATE SUBSCRIPTION financials<br />
CONNECTION 'dbname=libdata user=postgres host=172.17.0.2'<br />
PUBLICATION financials;<br />
NOTICE: synchronized table states<br />
NOTICE: created replication slot "financials" on publisher<br />
CREATE SUBSCRIPTION<br />
<br />
<br />
This will first copy a snapshot of the data currently in the tables, and then start catching up from the transaction log. Once it's caught up, you can check status in pg_stat_subscription:<br />
<br />
<br />
libdata=# select * from pg_stat_subscription;<br />
-[ RECORD 1 ]---------+---------------------<br />
subid | 16475<br />
subname | financials<br />
pid | 167<br />
relid |<br />
received_lsn | 0/1FBEAF0<br />
last_msg_send_time | 2017-06-07 00:59:44<br />
last_msg_receipt_time | 2017-06-07 00:59:44<br />
latest_end_lsn | 0/1FBEAF0<br />
latest_end_time | 2017-06-07 00:59:44<br />
<br />
<br />
blogs:<br />
<br />
* [https://blog.2ndquadrant.com/logical-replication-postgresql-10/ Logical Replication in PostgreSQL 10]<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
While version 9.6 introduced quorum based synchronous replication, <br />
<br />
synchronous_commit = 'remote_apply'<br />
<br />
version 10 improves the synchronous_standby_names GUC by adding the FIRST and ANY keywords:<br />
<br />
synchronous_standby_names = ANY 2(node1,node2,node3);<br />
synchronous_standby_names = FIRST 2(node1,node2);<br />
<br />
FIRST was the previous behaviour, and the nodes priority is following the list order in order to get a quorum. ANY now means that any node in the list is now able to provide the required quorum. This will give extra flexibility to complex replication setups.<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
[http://paquier.xyz/postgresql-2/postgres-10-libpq-read-write/ Implement failover on libpq connect level]<br />
<br />
=== Traceable Commit ===<br />
<br />
[https://blog.2ndquadrant.com/traceable-commit-postgresql-10/ Traceable commit for PostgreSQL 10]<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Identity Columns ===<br />
<br />
[https://blog.2ndquadrant.com/postgresql-10-identity-columns/ PostgreSQL 10 identity columns explained]<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
You can now create Full Text Indexes on JSON and JSONB columns.<br />
<br />
This involves converting the JSONB field to a `tsvector`, then creating an specific language full-text index on it:<br />
<br />
<br />
libdata=# CREATE INDEX bookdata_fts ON bookdata<br />
USING gin (( to_tsvector('english',bookdata) ));<br />
CREATE INDEX<br />
<br />
Once that's set up, you can do full-text searching against all of the values in your JSON documents:<br />
<br />
libdata=# SELECT bookdata -> 'title'<br />
FROM bookdata<br />
WHERE to_tsvector('english',bookdata) @@ to_tsquery('duke'); <br />
------------------------------------------<br />
"The Tattooed Duke"<br />
"She Tempts the Duke"<br />
"The Duke Is Mine"<br />
"What I Did For a Duke"<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Cross-column Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
[https://blog.2ndquadrant.com/pg-phriday-crazy-correlated-column-crusade/ PG Phriday: Crazy Correlated Column Crusade]<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===<br />
<br />
[https://blog.2ndquadrant.com/icu-support-postgresql-10/ More robust collations with ICU support in PostgreSQL 10]<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation. Users should specifically test for the incompatibilities before upgrading in production.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally (and location/lsn) ===<br />
<br />
In order to avoid confusion leading to data loss, everywhere we previously used the abbreviation "xlog" to refer to the transaction log, including directories, functions, and parameters for executables, we now use "wal". Similarly, the word "location" in function names, where used to refer to transaction log location, has been replaced with "lsn".<br />
<br />
This will require many users to reprogram custom backup and transaction log management scripts, as well as monitoring replication.<br />
<br />
Two directories have been renamed:<br />
<br />
{|<br />
! 9.6 Directory !! 10 Directory<br />
|-<br />
| pg_xlog || pg_wal<br />
|-<br />
| pg_clog || pg_commit_ts<br />
|}<br />
<br />
Many administrative functions have been renamed to use "wal" and "lsn":<br />
<br />
{|<br />
! 9.6 Function Name !! 10 Function Name <br />
|-<br />
| pg_current_xlog_flush_location || pg_current_wal_flush_lsn<br />
|-<br />
| pg_current_xlog_insert_location || pg_current_wal_insert_lsn<br />
|-<br />
| pg_current_xlog_location || pg_current_wal_lsn<br />
|-<br />
| pg_is_xlog_replay_paused || pg_is_wal_replay_paused<br />
|-<br />
| pg_last_xlog_receive_location || pg_last_wal_receive_lsn<br />
|-<br />
| pg_last_xlog_replay_location || pg_last_wal_replay_lsn<br />
|-<br />
| pg_switch_xlog || pg_switch_wal<br />
|-<br />
| pg_xlog_location_diff || pg_wal_lsn_diff<br />
|-<br />
| pg_xlog_replay_pause || pg_wal_replay_pause<br />
|-<br />
| pg_xlog_replay_resume || pg_wal_replay_resume<br />
|-<br />
| pg_xlogfile_name || pg_walfile_name<br />
|-<br />
| pg_xlogfile_name_offset || pg_walfile_name_offset<br />
|}<br />
<br />
Several command-line executables have had parameters renamed:<br />
<br />
TBD<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.0 ===<br />
<br />
Databases running on PostgreSQL version 7.4 and earlier will not be supported by 10's pg_dump or pg_dumpall. If you need to convert a database that old, use version 9.6 or earlier to upgrade it in two stages.</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30605New in postgres 102017-07-17T23:44:33Z<p>Aglio: /* Renaming of "xlog" to "wal" Globally */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
In 10, partitioning tables is now an attribute of the table:<br />
<br />
CREATE TABLE table_name ( ... )<br />
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) }<br />
<br />
CREATE TABLE table_name<br />
PARTITION OF parent_table [ (<br />
) ] FOR VALUES partition_bound_spec<br />
'''<br />
Example'''<br />
<br />
Before:<br />
CREATE TABLE padre (<br />
id serial,<br />
pais integer,<br />
fch_creado timestamptz not null<br />
);<br />
<br />
CREATE TABLE hija_2017 (<br />
CONSTRAINT pk_2017 PRIMARY KEY (id),<br />
CONSTRAINT ck_2017 CHECK (fch_creado < DATE '2015-01-01' )<br />
) INHERITS (padre);<br />
CREATE INDEX idx_2017 ON hija_2017 (fch_creado);<br />
<br />
Today:<br />
CREATE TABLE padre (<br />
id serial not null,<br />
nombre text not null,<br />
fch_creado timestamptz not null<br />
)<br />
PARTITION BY RANGE ( id );<br />
<br />
CREATE TABLE hijo_0<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (unbounded) to (9);<br />
<br />
CREATE TABLE hijo_1<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (10) to (unbounded);<br />
<br />
This means that users no longer need to create triggers for routing data; it's all handled by the system.<br />
<br />
'''Another Example:'''<br />
<br />
For example, we might decide to partition the `book_history` table, probably a good idea since that table is liable to accumulate data forever. Since it's a log table, we'll range partition it, with one partition per month.<br />
<br />
First, we create a "master" partition table, which will hold no data but forms a template for the rest of the partitions:<br />
<br />
<br />
libdata=# CREATE TABLE book_history (<br />
book_id INTEGER NOT NULL,<br />
status BOOK_STATUS NOT NULL,<br />
period TSTZRANGE NOT NULL )<br />
PARTITION BY RANGE ( lower (period) );<br />
<br />
<br />
Then we create several partitions, one per month:<br />
<br />
<br />
libdata=# CREATE TABLE book_history_2016_09<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-09-01 00:00:00') TO ('2016-10-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_08<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-08-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_07<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-07-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
ERROR: partition "book_history_2016_07" would overlap partition "book_history_2016_08"<br />
<br />
<br />
As you can see, the system even prevents accidental overlap. New rows will automatically be stored in the correct partition, and SELECT queries will search the appropriate partitions.<br />
<br />
<br />
<br />
* [https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 commit]<br />
* [https://www.postgresql.org/docs/devel/static/ddl-partitioning.html#ddl-partitioning-declarative Documentation]<br />
* [https://www.keithf4.com/postgresql-10-built-in-partitioning/ Built-in Partitioning]<br />
<br />
=== Additional Parallelism ===<br />
<br />
Some additional plan nodes can be executed in parallel, particularly Index Scans.<br />
<br />
'''Example:'''<br />
<br />
For example, if we wanted to search financial transaction history by an indexed column, I can now execute it in one-quarter the time by using four parallel workers:<br />
<br />
accounts=# \timing<br />
Timing is on.<br />
accounts=# select bid, count(*) from account_history<br />
where delta > 1000 group by bid;<br />
...<br />
Time: 324.903 ms<br />
<br />
accounts=# set max_parallel_workers_per_gather=4;<br />
SET<br />
Time: 0.822 ms<br />
accounts=# select bid, count(*) from account_history<br />
where delta > 1000 group by bid;<br />
...<br />
Time: 72.864 ms<br />
<br />
(this assumes an index on bid, delta)<br />
<br />
Links:<br />
<br />
* [http://rhaas.blogspot.com.ar/2017/03/parallel-query-v2.html Parallel Query v2]<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
example:<br />
<br />
Suppose I decide I want to replicate just the fines and loans tables from my public library database to the billing system so that they can process amounts owed. I would create a publication from those two tables with this command:<br />
<br />
<br />
libdata=# CREATE PUBLICATION financials FOR TABLE ONLY loans, ONLY fines;<br />
CREATE PUBLICATION<br />
<br />
<br />
Then, in the billing database, I would create two tables that looked identical to the tables I'm replicating, and have the same names. They can have additional columns and a few other differences. Particularly, since I'm not copying the patrons or books tables, I'll want to drop some foreign keys that they origin database has. I also need to create any special data types or other database artifacts required for those tables. Often the easiest way to do this is selective use of the `pg_dump` and `pg_restore` backup utilities:<br />
<br />
<br />
origin# pg_dump libdata -Fc -f /netshare/libdata.dump<br />
<br />
replica# pg_restore -d libdata -s -t loans -t fines /netshare/libdata.dump<br />
<br />
<br />
Following that, I can start a Subscription to those two tables:<br />
<br />
<br />
libdata=# CREATE SUBSCRIPTION financials<br />
CONNECTION 'dbname=libdata user=postgres host=172.17.0.2'<br />
PUBLICATION financials;<br />
NOTICE: synchronized table states<br />
NOTICE: created replication slot "financials" on publisher<br />
CREATE SUBSCRIPTION<br />
<br />
<br />
This will first copy a snapshot of the data currently in the tables, and then start catching up from the transaction log. Once it's caught up, you can check status in pg_stat_subscription:<br />
<br />
<br />
libdata=# select * from pg_stat_subscription;<br />
-[ RECORD 1 ]---------+---------------------<br />
subid | 16475<br />
subname | financials<br />
pid | 167<br />
relid |<br />
received_lsn | 0/1FBEAF0<br />
last_msg_send_time | 2017-06-07 00:59:44<br />
last_msg_receipt_time | 2017-06-07 00:59:44<br />
latest_end_lsn | 0/1FBEAF0<br />
latest_end_time | 2017-06-07 00:59:44<br />
<br />
<br />
blogs:<br />
<br />
* [https://blog.2ndquadrant.com/logical-replication-postgresql-10/ Logical Replication in PostgreSQL 10]<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
While version 9.6 introduced quorum based synchronous replication, <br />
<br />
synchronous_commit = 'remote_apply'<br />
<br />
version 10 improves the synchronous_standby_names GUC by adding the FIRST and ANY keywords:<br />
<br />
synchronous_standby_names = ANY 2(node1,node2,node3);<br />
synchronous_standby_names = FIRST 2(node1,node2);<br />
<br />
FIRST was the previous behaviour, and the nodes priority is following the list order in order to get a quorum. ANY now means that any node in the list is now able to provide the required quorum. This will give extra flexibility to complex replication setups.<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
[http://paquier.xyz/postgresql-2/postgres-10-libpq-read-write/ Implement failover on libpq connect level]<br />
<br />
=== Traceable Commit ===<br />
<br />
[https://blog.2ndquadrant.com/traceable-commit-postgresql-10/ Traceable commit for PostgreSQL 10]<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Identity Columns ===<br />
<br />
[https://blog.2ndquadrant.com/postgresql-10-identity-columns/ PostgreSQL 10 identity columns explained]<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
You can now create Full Text Indexes on JSON and JSONB columns.<br />
<br />
This involves converting the JSONB field to a `tsvector`, then creating an specific language full-text index on it:<br />
<br />
<br />
libdata=# CREATE INDEX bookdata_fts ON bookdata<br />
USING gin (( to_tsvector('english',bookdata) ));<br />
CREATE INDEX<br />
<br />
Once that's set up, you can do full-text searching against all of the values in your JSON documents:<br />
<br />
libdata=# SELECT bookdata -> 'title'<br />
FROM bookdata<br />
WHERE to_tsvector('english',bookdata) @@ to_tsquery('duke'); <br />
------------------------------------------<br />
"The Tattooed Duke"<br />
"She Tempts the Duke"<br />
"The Duke Is Mine"<br />
"What I Did For a Duke"<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Cross-column Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
[https://blog.2ndquadrant.com/pg-phriday-crazy-correlated-column-crusade/ PG Phriday: Crazy Correlated Column Crusade]<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===<br />
<br />
[https://blog.2ndquadrant.com/icu-support-postgresql-10/ More robust collations with ICU support in PostgreSQL 10]<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation. Users should specifically test for the incompatibilities before upgrading in production.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally (and location/lsn) ===<br />
<br />
In order to avoid confusion leading to data loss, everywhere we previously used the abbreviation "xlog" to refer to the transaction log, including directories, functions, and parameters for executables, we now use "wal". Similarly, the word "location" in function names, where used to refer to transaction log location, has been replaced with "lsn".<br />
<br />
This will require many users to reprogram custom backup and transaction log management scripts, as well as monitoring replication.<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.0 ===<br />
<br />
Databases running on PostgreSQL version 7.4 and earlier will not be supported by 10's pg_dump or pg_dumpall. If you need to convert a database that old, use version 9.6 or earlier to upgrade it in two stages.</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30416New in postgres 102017-06-13T00:29:38Z<p>Aglio: /* Full Text Search support for JSON and JSONB */ added example from my lwn article.</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
In 10, partitioning tables is now an attribute of the table:<br />
<br />
CREATE TABLE table_name ( ... )<br />
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) }<br />
<br />
CREATE TABLE table_name<br />
PARTITION OF parent_table [ (<br />
) ] FOR VALUES partition_bound_spec<br />
'''<br />
Example'''<br />
<br />
Before:<br />
CREATE TABLE padre (<br />
id serial,<br />
pais integer,<br />
fch_creado timestamptz not null<br />
);<br />
<br />
CREATE TABLE hija_2017 (<br />
CONSTRAINT pk_2017 PRIMARY KEY (id),<br />
CONSTRAINT ck_2017 CHECK (fch_creado < DATE '2015-01-01' )<br />
) INHERITS (padre);<br />
CREATE INDEX idx_2017 ON hija_2017 (fch_creado);<br />
<br />
Today:<br />
CREATE TABLE padre (<br />
id serial not null,<br />
nombre text not null,<br />
fch_creado timestamptz not null<br />
)<br />
PARTITION BY RANGE ( id );<br />
<br />
CREATE TABLE hijo_0<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (unbounded) to (9);<br />
<br />
CREATE TABLE hijo_1<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (10) to (unbounded);<br />
<br />
This means that users no longer need to create triggers for routing data; it's all handled by the system.<br />
<br />
'''Another Example:'''<br />
<br />
For example, we might decide to partition the `book_history` table, probably a good idea since that table is liable to accumulate data forever. Since it's a log table, we'll range partition it, with one partition per month.<br />
<br />
First, we create a "master" partition table, which will hold no data but forms a template for the rest of the partitions:<br />
<br />
<br />
libdata=# CREATE TABLE book_history (<br />
book_id INTEGER NOT NULL,<br />
status BOOK_STATUS NOT NULL,<br />
period TSTZRANGE NOT NULL )<br />
PARTITION BY RANGE ( lower (period) );<br />
<br />
<br />
Then we create several partitions, one per month:<br />
<br />
<br />
libdata=# CREATE TABLE book_history_2016_09<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-09-01 00:00:00') TO ('2016-10-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_08<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-08-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_07<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-07-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
ERROR: partition "book_history_2016_07" would overlap partition "book_history_2016_08"<br />
<br />
<br />
As you can see, the system even prevents accidental overlap. New rows will automatically be stored in the correct partition, and SELECT queries will search the appropriate partitions.<br />
<br />
<br />
<br />
* [https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 commit]<br />
* [https://www.postgresql.org/docs/devel/static/ddl-partitioning.html#ddl-partitioning-declarative Documentation]<br />
* [https://www.keithf4.com/postgresql-10-built-in-partitioning/ Built-in Partitioning]<br />
<br />
=== Additional Parallelism ===<br />
<br />
Some additional plan nodes can be executed in parallel, particularly Index Scans.<br />
<br />
'''Example:'''<br />
<br />
For example, if we wanted to search financial transaction history by an indexed column, I can now execute it in one-quarter the time by using four parallel workers:<br />
<br />
accounts=# \timing<br />
Timing is on.<br />
accounts=# select bid, count(*) from account_history<br />
where delta > 1000 group by bid;<br />
...<br />
Time: 324.903 ms<br />
<br />
accounts=# set max_parallel_workers_per_gather=4;<br />
SET<br />
Time: 0.822 ms<br />
accounts=# select bid, count(*) from account_history<br />
where delta > 1000 group by bid;<br />
...<br />
Time: 72.864 ms<br />
<br />
(this assumes an index on bid, delta)<br />
<br />
Links:<br />
<br />
* [http://rhaas.blogspot.com.ar/2017/03/parallel-query-v2.html Parallel Query v2]<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
example:<br />
<br />
Suppose I decide I want to replicate just the fines and loans tables from my public library database to the billing system so that they can process amounts owed. I would create a publication from those two tables with this command:<br />
<br />
<br />
libdata=# CREATE PUBLICATION financials FOR TABLE ONLY loans, ONLY fines;<br />
CREATE PUBLICATION<br />
<br />
<br />
Then, in the billing database, I would create two tables that looked identical to the tables I'm replicating, and have the same names. They can have additional columns and a few other differences. Particularly, since I'm not copying the patrons or books tables, I'll want to drop some foreign keys that they origin database has. I also need to create any special data types or other database artifacts required for those tables. Often the easiest way to do this is selective use of the `pg_dump` and `pg_restore` backup utilities:<br />
<br />
<br />
origin# pg_dump libdata -Fc -f /netshare/libdata.dump<br />
<br />
replica# pg_restore -d libdata -s -t loans -t fines /netshare/libdata.dump<br />
<br />
<br />
Following that, I can start a Subscription to those two tables:<br />
<br />
<br />
libdata=# CREATE SUBSCRIPTION financials<br />
CONNECTION 'dbname=libdata user=postgres host=172.17.0.2'<br />
PUBLICATION financials;<br />
NOTICE: synchronized table states<br />
NOTICE: created replication slot "financials" on publisher<br />
CREATE SUBSCRIPTION<br />
<br />
<br />
This will first copy a snapshot of the data currently in the tables, and then start catching up from the transaction log. Once it's caught up, you can check status in pg_stat_subscription:<br />
<br />
<br />
libdata=# select * from pg_stat_subscription;<br />
-[ RECORD 1 ]---------+---------------------<br />
subid | 16475<br />
subname | financials<br />
pid | 167<br />
relid |<br />
received_lsn | 0/1FBEAF0<br />
last_msg_send_time | 2017-06-07 00:59:44<br />
last_msg_receipt_time | 2017-06-07 00:59:44<br />
latest_end_lsn | 0/1FBEAF0<br />
latest_end_time | 2017-06-07 00:59:44<br />
<br />
<br />
blogs:<br />
<br />
* [https://blog.2ndquadrant.com/logical-replication-postgresql-10/ Logical Replication in PostgreSQL 10]<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
While version 9.6 introduced quorum based synchronous replication, <br />
<br />
synchronous_commit = 'remote_apply'<br />
<br />
All quorum nodes must be up to date, When are many, should everyone expect to be updated by the Master?<br />
<br />
version 10, improves the synchronous_standby_names GUC by adding the FIRST and ANY keywords.<br />
<br />
synchronous_standby_names = ANY 2(node1,node2,node3);<br />
<br />
synchronous_standby_names = FIRST 2(node1,node2);<br />
<br />
FIRST was the previous behaviour, and the nodes priority is following the list order in order to get a quorum. ANY now means that any node in the list is now able to provide the required quorum. This will give extra flexibility to complex replication setups.<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
[http://paquier.xyz/postgresql-2/postgres-10-libpq-read-write/ Implement failover on libpq connect level]<br />
<br />
=== Traceable Commit ===<br />
<br />
[https://blog.2ndquadrant.com/traceable-commit-postgresql-10/ Traceable commit for PostgreSQL 10]<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Identity Columns ===<br />
<br />
[https://blog.2ndquadrant.com/postgresql-10-identity-columns/ PostgreSQL 10 identity columns explained]<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
You can now create Full Text Indexes on JSON and JSONB columns.<br />
<br />
This involves converting the JSONB field to a `tsvector`, then creating an specific language full-text index on it:<br />
<br />
<br />
libdata=# CREATE INDEX bookdata_fts ON bookdata<br />
USING gin (( to_tsvector('english',bookdata) ));<br />
CREATE INDEX<br />
<br />
Once that's set up, you can do full-text searching against all of the values in your JSON documents:<br />
<br />
libdata=# SELECT bookdata -> 'title'<br />
FROM bookdata<br />
WHERE to_tsvector('english',bookdata) @@ to_tsquery('duke'); <br />
------------------------------------------<br />
"The Tattooed Duke"<br />
"She Tempts the Duke"<br />
"The Duke Is Mine"<br />
"What I Did For a Duke"<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Cross-column Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===<br />
<br />
[https://blog.2ndquadrant.com/icu-support-postgresql-10/ More robust collations with ICU support in PostgreSQL 10]<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation. Users should specifically test for the incompatibilities before upgrading in production.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.0 ===<br />
<br />
Databases running on PostgreSQL version 7.4 and earlier will not be supported by 10's pg_dump or pg_dumpall. If you need to convert a database that old, use version 9.6 or earlier to upgrade it in two stages.</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30415New in postgres 102017-06-13T00:27:52Z<p>Aglio: /* Additional Parallelism */ added parallel query example from my lwn article.</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
In 10, partitioning tables is now an attribute of the table:<br />
<br />
CREATE TABLE table_name ( ... )<br />
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) }<br />
<br />
CREATE TABLE table_name<br />
PARTITION OF parent_table [ (<br />
) ] FOR VALUES partition_bound_spec<br />
'''<br />
Example'''<br />
<br />
Before:<br />
CREATE TABLE padre (<br />
id serial,<br />
pais integer,<br />
fch_creado timestamptz not null<br />
);<br />
<br />
CREATE TABLE hija_2017 (<br />
CONSTRAINT pk_2017 PRIMARY KEY (id),<br />
CONSTRAINT ck_2017 CHECK (fch_creado < DATE '2015-01-01' )<br />
) INHERITS (padre);<br />
CREATE INDEX idx_2017 ON hija_2017 (fch_creado);<br />
<br />
Today:<br />
CREATE TABLE padre (<br />
id serial not null,<br />
nombre text not null,<br />
fch_creado timestamptz not null<br />
)<br />
PARTITION BY RANGE ( id );<br />
<br />
CREATE TABLE hijo_0<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (unbounded) to (9);<br />
<br />
CREATE TABLE hijo_1<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (10) to (unbounded);<br />
<br />
This means that users no longer need to create triggers for routing data; it's all handled by the system.<br />
<br />
'''Another Example:'''<br />
<br />
For example, we might decide to partition the `book_history` table, probably a good idea since that table is liable to accumulate data forever. Since it's a log table, we'll range partition it, with one partition per month.<br />
<br />
First, we create a "master" partition table, which will hold no data but forms a template for the rest of the partitions:<br />
<br />
<br />
libdata=# CREATE TABLE book_history (<br />
book_id INTEGER NOT NULL,<br />
status BOOK_STATUS NOT NULL,<br />
period TSTZRANGE NOT NULL )<br />
PARTITION BY RANGE ( lower (period) );<br />
<br />
<br />
Then we create several partitions, one per month:<br />
<br />
<br />
libdata=# CREATE TABLE book_history_2016_09<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-09-01 00:00:00') TO ('2016-10-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_08<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-08-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_07<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-07-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
ERROR: partition "book_history_2016_07" would overlap partition "book_history_2016_08"<br />
<br />
<br />
As you can see, the system even prevents accidental overlap. New rows will automatically be stored in the correct partition, and SELECT queries will search the appropriate partitions.<br />
<br />
<br />
<br />
* [https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 commit]<br />
* [https://www.postgresql.org/docs/devel/static/ddl-partitioning.html#ddl-partitioning-declarative Documentation]<br />
* [https://www.keithf4.com/postgresql-10-built-in-partitioning/ Built-in Partitioning]<br />
<br />
=== Additional Parallelism ===<br />
<br />
Some additional plan nodes can be executed in parallel, particularly Index Scans.<br />
<br />
'''Example:'''<br />
<br />
For example, if we wanted to search financial transaction history by an indexed column, I can now execute it in one-quarter the time by using four parallel workers:<br />
<br />
accounts=# \timing<br />
Timing is on.<br />
accounts=# select bid, count(*) from account_history<br />
where delta > 1000 group by bid;<br />
...<br />
Time: 324.903 ms<br />
<br />
accounts=# set max_parallel_workers_per_gather=4;<br />
SET<br />
Time: 0.822 ms<br />
accounts=# select bid, count(*) from account_history<br />
where delta > 1000 group by bid;<br />
...<br />
Time: 72.864 ms<br />
<br />
(this assumes an index on bid, delta)<br />
<br />
Links:<br />
<br />
* [http://rhaas.blogspot.com.ar/2017/03/parallel-query-v2.html Parallel Query v2]<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
example:<br />
<br />
Suppose I decide I want to replicate just the fines and loans tables from my public library database to the billing system so that they can process amounts owed. I would create a publication from those two tables with this command:<br />
<br />
<br />
libdata=# CREATE PUBLICATION financials FOR TABLE ONLY loans, ONLY fines;<br />
CREATE PUBLICATION<br />
<br />
<br />
Then, in the billing database, I would create two tables that looked identical to the tables I'm replicating, and have the same names. They can have additional columns and a few other differences. Particularly, since I'm not copying the patrons or books tables, I'll want to drop some foreign keys that they origin database has. I also need to create any special data types or other database artifacts required for those tables. Often the easiest way to do this is selective use of the `pg_dump` and `pg_restore` backup utilities:<br />
<br />
<br />
origin# pg_dump libdata -Fc -f /netshare/libdata.dump<br />
<br />
replica# pg_restore -d libdata -s -t loans -t fines /netshare/libdata.dump<br />
<br />
<br />
Following that, I can start a Subscription to those two tables:<br />
<br />
<br />
libdata=# CREATE SUBSCRIPTION financials<br />
CONNECTION 'dbname=libdata user=postgres host=172.17.0.2'<br />
PUBLICATION financials;<br />
NOTICE: synchronized table states<br />
NOTICE: created replication slot "financials" on publisher<br />
CREATE SUBSCRIPTION<br />
<br />
<br />
This will first copy a snapshot of the data currently in the tables, and then start catching up from the transaction log. Once it's caught up, you can check status in pg_stat_subscription:<br />
<br />
<br />
libdata=# select * from pg_stat_subscription;<br />
-[ RECORD 1 ]---------+---------------------<br />
subid | 16475<br />
subname | financials<br />
pid | 167<br />
relid |<br />
received_lsn | 0/1FBEAF0<br />
last_msg_send_time | 2017-06-07 00:59:44<br />
last_msg_receipt_time | 2017-06-07 00:59:44<br />
latest_end_lsn | 0/1FBEAF0<br />
latest_end_time | 2017-06-07 00:59:44<br />
<br />
<br />
blogs:<br />
<br />
* [https://blog.2ndquadrant.com/logical-replication-postgresql-10/ Logical Replication in PostgreSQL 10]<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
While version 9.6 introduced quorum based synchronous replication, <br />
<br />
synchronous_commit = 'remote_apply'<br />
<br />
All quorum nodes must be up to date, When are many, should everyone expect to be updated by the Master?<br />
<br />
version 10, improves the synchronous_standby_names GUC by adding the FIRST and ANY keywords.<br />
<br />
synchronous_standby_names = ANY 2(node1,node2,node3);<br />
<br />
synchronous_standby_names = FIRST 2(node1,node2);<br />
<br />
FIRST was the previous behaviour, and the nodes priority is following the list order in order to get a quorum. ANY now means that any node in the list is now able to provide the required quorum. This will give extra flexibility to complex replication setups.<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
[http://paquier.xyz/postgresql-2/postgres-10-libpq-read-write/ Implement failover on libpq connect level]<br />
<br />
=== Traceable Commit ===<br />
<br />
[https://blog.2ndquadrant.com/traceable-commit-postgresql-10/ Traceable commit for PostgreSQL 10]<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Identity Columns ===<br />
<br />
[https://blog.2ndquadrant.com/postgresql-10-identity-columns/ PostgreSQL 10 identity columns explained]<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Cross-column Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===<br />
<br />
[https://blog.2ndquadrant.com/icu-support-postgresql-10/ More robust collations with ICU support in PostgreSQL 10]<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation. Users should specifically test for the incompatibilities before upgrading in production.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.0 ===<br />
<br />
Databases running on PostgreSQL version 7.4 and earlier will not be supported by 10's pg_dump or pg_dumpall. If you need to convert a database that old, use version 9.6 or earlier to upgrade it in two stages.</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30414New in postgres 102017-06-13T00:25:56Z<p>Aglio: /* Native Partitioning */ added partitioning example from my LWN article.</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
In 10, partitioning tables is now an attribute of the table:<br />
<br />
CREATE TABLE table_name ( ... )<br />
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) }<br />
<br />
CREATE TABLE table_name<br />
PARTITION OF parent_table [ (<br />
) ] FOR VALUES partition_bound_spec<br />
'''<br />
Example'''<br />
<br />
Before:<br />
CREATE TABLE padre (<br />
id serial,<br />
pais integer,<br />
fch_creado timestamptz not null<br />
);<br />
<br />
CREATE TABLE hija_2017 (<br />
CONSTRAINT pk_2017 PRIMARY KEY (id),<br />
CONSTRAINT ck_2017 CHECK (fch_creado < DATE '2015-01-01' )<br />
) INHERITS (padre);<br />
CREATE INDEX idx_2017 ON hija_2017 (fch_creado);<br />
<br />
Today:<br />
CREATE TABLE padre (<br />
id serial not null,<br />
nombre text not null,<br />
fch_creado timestamptz not null<br />
)<br />
PARTITION BY RANGE ( id );<br />
<br />
CREATE TABLE hijo_0<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (unbounded) to (9);<br />
<br />
CREATE TABLE hijo_1<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (10) to (unbounded);<br />
<br />
This means that users no longer need to create triggers for routing data; it's all handled by the system.<br />
<br />
'''Another Example:'''<br />
<br />
For example, we might decide to partition the `book_history` table, probably a good idea since that table is liable to accumulate data forever. Since it's a log table, we'll range partition it, with one partition per month.<br />
<br />
First, we create a "master" partition table, which will hold no data but forms a template for the rest of the partitions:<br />
<br />
<br />
libdata=# CREATE TABLE book_history (<br />
book_id INTEGER NOT NULL,<br />
status BOOK_STATUS NOT NULL,<br />
period TSTZRANGE NOT NULL )<br />
PARTITION BY RANGE ( lower (period) );<br />
<br />
<br />
Then we create several partitions, one per month:<br />
<br />
<br />
libdata=# CREATE TABLE book_history_2016_09<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-09-01 00:00:00') TO ('2016-10-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_08<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-08-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
CREATE TABLE<br />
libdata=# CREATE TABLE book_history_2016_07<br />
PARTITION OF book_history<br />
FOR VALUES FROM ('2016-07-01 00:00:00') TO ('2016-09-01 00:00:00');<br />
ERROR: partition "book_history_2016_07" would overlap partition "book_history_2016_08"<br />
<br />
<br />
As you can see, the system even prevents accidental overlap. New rows will automatically be stored in the correct partition, and SELECT queries will search the appropriate partitions.<br />
<br />
<br />
<br />
* [https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 commit]<br />
* [https://www.postgresql.org/docs/devel/static/ddl-partitioning.html#ddl-partitioning-declarative Documentation]<br />
* [https://www.keithf4.com/postgresql-10-built-in-partitioning/ Built-in Partitioning]<br />
<br />
=== Additional Parallelism ===<br />
<br />
Some additional plan nodes can be executed in parallel.<br />
<br />
[http://rhaas.blogspot.com.ar/2017/03/parallel-query-v2.html Parallel Query v2]<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
example:<br />
<br />
Suppose I decide I want to replicate just the fines and loans tables from my public library database to the billing system so that they can process amounts owed. I would create a publication from those two tables with this command:<br />
<br />
<br />
libdata=# CREATE PUBLICATION financials FOR TABLE ONLY loans, ONLY fines;<br />
CREATE PUBLICATION<br />
<br />
<br />
Then, in the billing database, I would create two tables that looked identical to the tables I'm replicating, and have the same names. They can have additional columns and a few other differences. Particularly, since I'm not copying the patrons or books tables, I'll want to drop some foreign keys that they origin database has. I also need to create any special data types or other database artifacts required for those tables. Often the easiest way to do this is selective use of the `pg_dump` and `pg_restore` backup utilities:<br />
<br />
<br />
origin# pg_dump libdata -Fc -f /netshare/libdata.dump<br />
<br />
replica# pg_restore -d libdata -s -t loans -t fines /netshare/libdata.dump<br />
<br />
<br />
Following that, I can start a Subscription to those two tables:<br />
<br />
<br />
libdata=# CREATE SUBSCRIPTION financials<br />
CONNECTION 'dbname=libdata user=postgres host=172.17.0.2'<br />
PUBLICATION financials;<br />
NOTICE: synchronized table states<br />
NOTICE: created replication slot "financials" on publisher<br />
CREATE SUBSCRIPTION<br />
<br />
<br />
This will first copy a snapshot of the data currently in the tables, and then start catching up from the transaction log. Once it's caught up, you can check status in pg_stat_subscription:<br />
<br />
<br />
libdata=# select * from pg_stat_subscription;<br />
-[ RECORD 1 ]---------+---------------------<br />
subid | 16475<br />
subname | financials<br />
pid | 167<br />
relid |<br />
received_lsn | 0/1FBEAF0<br />
last_msg_send_time | 2017-06-07 00:59:44<br />
last_msg_receipt_time | 2017-06-07 00:59:44<br />
latest_end_lsn | 0/1FBEAF0<br />
latest_end_time | 2017-06-07 00:59:44<br />
<br />
<br />
blogs:<br />
<br />
* [https://blog.2ndquadrant.com/logical-replication-postgresql-10/ Logical Replication in PostgreSQL 10]<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
While version 9.6 introduced quorum based synchronous replication, <br />
<br />
synchronous_commit = 'remote_apply'<br />
<br />
All quorum nodes must be up to date, When are many, should everyone expect to be updated by the Master?<br />
<br />
version 10, improves the synchronous_standby_names GUC by adding the FIRST and ANY keywords.<br />
<br />
synchronous_standby_names = ANY 2(node1,node2,node3);<br />
<br />
synchronous_standby_names = FIRST 2(node1,node2);<br />
<br />
FIRST was the previous behaviour, and the nodes priority is following the list order in order to get a quorum. ANY now means that any node in the list is now able to provide the required quorum. This will give extra flexibility to complex replication setups.<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
[http://paquier.xyz/postgresql-2/postgres-10-libpq-read-write/ Implement failover on libpq connect level]<br />
<br />
=== Traceable Commit ===<br />
<br />
[https://blog.2ndquadrant.com/traceable-commit-postgresql-10/ Traceable commit for PostgreSQL 10]<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Identity Columns ===<br />
<br />
[https://blog.2ndquadrant.com/postgresql-10-identity-columns/ PostgreSQL 10 identity columns explained]<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Cross-column Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===<br />
<br />
[https://blog.2ndquadrant.com/icu-support-postgresql-10/ More robust collations with ICU support in PostgreSQL 10]<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation. Users should specifically test for the incompatibilities before upgrading in production.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.0 ===<br />
<br />
Databases running on PostgreSQL version 7.4 and earlier will not be supported by 10's pg_dump or pg_dumpall. If you need to convert a database that old, use version 9.6 or earlier to upgrade it in two stages.</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30413New in postgres 102017-06-13T00:22:52Z<p>Aglio: /* Logical Replication */ added logical replication example from my LWN article.</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
In 10, partitioning tables is now an attribute of the table:<br />
<br />
CREATE TABLE table_name ( ... )<br />
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) }<br />
<br />
CREATE TABLE table_name<br />
PARTITION OF parent_table [ (<br />
) ] FOR VALUES partition_bound_spec<br />
'''<br />
Example'''<br />
<br />
Before:<br />
CREATE TABLE padre (<br />
id serial,<br />
pais integer,<br />
fch_creado timestamptz not null<br />
);<br />
<br />
CREATE TABLE hija_2017 (<br />
CONSTRAINT pk_2017 PRIMARY KEY (id),<br />
CONSTRAINT ck_2017 CHECK (fch_creado < DATE '2015-01-01' )<br />
) INHERITS (padre);<br />
CREATE INDEX idx_2017 ON hija_2017 (fch_creado);<br />
<br />
Today:<br />
CREATE TABLE padre (<br />
id serial not null,<br />
nombre text not null,<br />
fch_creado timestamptz not null<br />
)<br />
PARTITION BY RANGE ( id );<br />
<br />
CREATE TABLE hijo_0<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (unbounded) to (9);<br />
<br />
CREATE TABLE hijo_1<br />
partition of padre (id, primary key (id), unique (nombre))<br />
for values from (10) to (unbounded);<br />
<br />
This means that users no longer need to create triggers for routing data; it's all handled by the system.<br />
<br />
* [https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 commit]<br />
* [https://www.postgresql.org/docs/devel/static/ddl-partitioning.html#ddl-partitioning-declarative Documentation]<br />
* [https://www.keithf4.com/postgresql-10-built-in-partitioning/ Built-in Partitioning]<br />
<br />
=== Additional Parallelism ===<br />
<br />
Some additional plan nodes can be executed in parallel.<br />
<br />
[http://rhaas.blogspot.com.ar/2017/03/parallel-query-v2.html Parallel Query v2]<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
example:<br />
<br />
Suppose I decide I want to replicate just the fines and loans tables from my public library database to the billing system so that they can process amounts owed. I would create a publication from those two tables with this command:<br />
<br />
<br />
libdata=# CREATE PUBLICATION financials FOR TABLE ONLY loans, ONLY fines;<br />
CREATE PUBLICATION<br />
<br />
<br />
Then, in the billing database, I would create two tables that looked identical to the tables I'm replicating, and have the same names. They can have additional columns and a few other differences. Particularly, since I'm not copying the patrons or books tables, I'll want to drop some foreign keys that they origin database has. I also need to create any special data types or other database artifacts required for those tables. Often the easiest way to do this is selective use of the `pg_dump` and `pg_restore` backup utilities:<br />
<br />
<br />
origin# pg_dump libdata -Fc -f /netshare/libdata.dump<br />
<br />
replica# pg_restore -d libdata -s -t loans -t fines /netshare/libdata.dump<br />
<br />
<br />
Following that, I can start a Subscription to those two tables:<br />
<br />
<br />
libdata=# CREATE SUBSCRIPTION financials<br />
CONNECTION 'dbname=libdata user=postgres host=172.17.0.2'<br />
PUBLICATION financials;<br />
NOTICE: synchronized table states<br />
NOTICE: created replication slot "financials" on publisher<br />
CREATE SUBSCRIPTION<br />
<br />
<br />
This will first copy a snapshot of the data currently in the tables, and then start catching up from the transaction log. Once it's caught up, you can check status in pg_stat_subscription:<br />
<br />
<br />
libdata=# select * from pg_stat_subscription;<br />
-[ RECORD 1 ]---------+---------------------<br />
subid | 16475<br />
subname | financials<br />
pid | 167<br />
relid |<br />
received_lsn | 0/1FBEAF0<br />
last_msg_send_time | 2017-06-07 00:59:44<br />
last_msg_receipt_time | 2017-06-07 00:59:44<br />
latest_end_lsn | 0/1FBEAF0<br />
latest_end_time | 2017-06-07 00:59:44<br />
<br />
<br />
blogs:<br />
<br />
* [https://blog.2ndquadrant.com/logical-replication-postgresql-10/ Logical Replication in PostgreSQL 10]<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
While version 9.6 introduced quorum based synchronous replication, <br />
<br />
synchronous_commit = 'remote_apply'<br />
<br />
All quorum nodes must be up to date, When are many, should everyone expect to be updated by the Master?<br />
<br />
version 10, improves the synchronous_standby_names GUC by adding the FIRST and ANY keywords.<br />
<br />
synchronous_standby_names = ANY 2(node1,node2,node3);<br />
<br />
synchronous_standby_names = FIRST 2(node1,node2);<br />
<br />
FIRST was the previous behaviour, and the nodes priority is following the list order in order to get a quorum. ANY now means that any node in the list is now able to provide the required quorum. This will give extra flexibility to complex replication setups.<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
[http://paquier.xyz/postgresql-2/postgres-10-libpq-read-write/ Implement failover on libpq connect level]<br />
<br />
=== Traceable Commit ===<br />
<br />
[https://blog.2ndquadrant.com/traceable-commit-postgresql-10/ Traceable commit for PostgreSQL 10]<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Identity Columns ===<br />
<br />
[https://blog.2ndquadrant.com/postgresql-10-identity-columns/ PostgreSQL 10 identity columns explained]<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Cross-column Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===<br />
<br />
[https://blog.2ndquadrant.com/icu-support-postgresql-10/ More robust collations with ICU support in PostgreSQL 10]<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation. Users should specifically test for the incompatibilities before upgrading in production.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.0 ===<br />
<br />
Databases running on PostgreSQL version 7.4 and earlier will not be supported by 10's pg_dump or pg_dumpall. If you need to convert a database that old, use version 9.6 or earlier to upgrade it in two stages.</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30173New in postgres 102017-05-17T23:31:23Z<p>Aglio: Moved backwards-incompatible issues to bottom.</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
In 10, partitioning tables is now an attribute of the table:<br />
<br />
CREATE TABLE table_name ( ... )<br />
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) }<br />
<br />
CREATE TABLE table_name<br />
PARTITION OF parent_table [ (<br />
) ] FOR VALUES partition_bound_spec<br />
<br />
This means that users no longer need to create triggers for routing data; it's all handled by the system.<br />
<br />
* [https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 commit]<br />
* [https://www.keithf4.com/postgresql-10-built-in-partitioning/ Built-in Partitioning]<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
While version 9.6 introduced quorum based synchronous replication, version improves the synchronous_standby_names GUC by adding the FIRST and ANY keywords.<br />
<br />
synchronous_standby_names = ANY 2(node1,node2,node3);<br />
<br />
synchronous_standby_names = FIRST 2(node1,node2);<br />
<br />
FIRST was the previous behaviour, and the nodes priority is following the list order in order to get a quorum. ANY now means that any node in the list is now able to provide the required quorum. This will give extra flexibility to complex replication setups.<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation. Users should specifically test for the incompatibilities before upgrading in production.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.0 ===<br />
<br />
Databases running on PostgreSQL version 7.4 and earlier will not be supported by 10's pg_dump or pg_dumpall. If you need to convert a database that old, use version 9.6 or earlier to upgrade it in two stages.</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30172New in postgres 102017-05-17T22:32:38Z<p>Aglio: /* Backwards-Incompatible Changes */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation. Users should specifically test for the incompatibilities before upgrading in production.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.0 ===<br />
<br />
Databases running on PostgreSQL version 7.4 and earlier will not be supported by 10's pg_dump or pg_dumpall. If you need to convert a database that old, use version 9.6 or earlier to upgrade it in two stages.<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
In 10, partitioning tables is now an attribute of the table:<br />
<br />
CREATE TABLE table_name ( ... )<br />
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) }<br />
<br />
CREATE TABLE table_name<br />
PARTITION OF parent_table [ (<br />
) ] FOR VALUES partition_bound_spec<br />
<br />
This means that users no longer need to create triggers for routing data; it's all handled by the system.<br />
<br />
* [https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 commit]<br />
* [https://www.keithf4.com/postgresql-10-built-in-partitioning/ Built-in Partitioning]<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
While version 9.6 introduced quorum based synchronous replication, version improves the synchronous_standby_names GUC by adding the FIRST and ANY keywords.<br />
<br />
synchronous_standby_names = ANY 2(node1,node2,node3);<br />
<br />
synchronous_standby_names = FIRST 2(node1,node2);<br />
<br />
FIRST was the previous behaviour, and the nodes priority is following the list order in order to get a quorum. ANY now means that any node in the list is now able to provide the required quorum. This will give extra flexibility to complex replication setups.<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30171New in postgres 102017-05-17T22:27:16Z<p>Aglio: /* Native Partitioning */ added description, example</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.0 ===<br />
<br />
Databases running on PostgreSQL version 7.4 and earlier will not be supported by 10's pg_dump or pg_dumpall. If you need to convert a database that old, use version 9.6 or earlier to upgrade it in two stages.<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
In 10, partitioning tables is now an attribute of the table:<br />
<br />
CREATE TABLE table_name ( ... )<br />
[ PARTITION BY { RANGE | LIST } ( { column_name | ( expression ) }<br />
<br />
CREATE TABLE table_name<br />
PARTITION OF parent_table [ (<br />
) ] FOR VALUES partition_bound_spec<br />
<br />
This means that users no longer need to create triggers for routing data; it's all handled by the system.<br />
<br />
* [https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f0e44751d7175fa3394da2c8f85e3ceb3cdbfe63 commit]<br />
* [https://www.keithf4.com/postgresql-10-built-in-partitioning/ Built-in Partitioning]<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
While version 9.6 introduced quorum based synchronous replication, version improves the synchronous_standby_names GUC by adding the FIRST and ANY keywords.<br />
<br />
synchronous_standby_names = ANY 2(node1,node2,node3);<br />
<br />
synchronous_standby_names = FIRST 2(node1,node2);<br />
<br />
FIRST was the previous behaviour, and the nodes priority is following the list order in order to get a quorum. ANY now means that any node in the list is now able to provide the required quorum. This will give extra flexibility to complex replication setups.<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30169New in postgres 102017-05-17T21:36:38Z<p>Aglio: /* Drop pg_dump Support for Databases Older than 8.1 */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.0 ===<br />
<br />
Databases running on PostgreSQL version 7.4 and earlier will not be supported by 10's pg_dump or pg_dumpall. If you need to convert a database that old, use version 9.6 or earlier to upgrade it in two stages.<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
While version 9.6 introduced quorum based synchronous replication, version improves the synchronous_standby_names GUC by adding the FIRST and ANY keywords.<br />
<br />
synchronous_standby_names = ANY 2(node1,node2,node3);<br />
<br />
synchronous_standby_names = FIRST 2(node1,node2);<br />
<br />
FIRST was the previous behaviour, and the nodes priority is following the list order in order to get a quorum. ANY now means that any node in the list is now able to provide the required quorum. This will give extra flexibility to complex replication setups.<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30166New in postgres 102017-05-17T04:40:49Z<p>Aglio: /* Multi-column Correlation Statistics */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.1 ===<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples. This feature in PostgreSQL represents an advance in the state of the art for all SQL databases.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=PyCon_2017_Booth&diff=30162PyCon 2017 Booth2017-05-16T23:52:26Z<p>Aglio: /* 3:30pm - 4pm (High Traffic) */</p>
<hr />
<div>The PostgreSQL community booth at PyCon in Portland, Oregon is hosted by the Portland PostgreSQL Users Group. The dates are May 18-20 at the Oregon Convention Center. Please sign up by editing this wiki or emailing one of us before the end of the first full week of April for the t-shirt order.<br />
<br />
Contact one of us for more detail:<br />
<br />
* Gabrielle Roth <gorthx at gmail.com><br />
* Grant Holly <gdholly at gmail.com><br />
* Mark Wong <mark at 2ndQuadrant.com><br />
<br />
= Thursday May 18 (6pm to 8:30pm) - Opening Reception =<br />
<br />
* Mark Wong<br />
* Gabrielle Roth<br />
<br />
= Friday May 19 (8am to 5pm) =<br />
<br />
== 8am - 9:30am (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 9:30am - 10:30am ==<br />
<br />
* Mark Wong<br />
<br />
== 10:30am - 11am (High Traffic) ==<br />
<br />
* Mark Wong<br />
* Josh Berkus<br />
<br />
== 11am - 12:30pm ==<br />
<br />
* Mark Wong<br />
<br />
== 12:30pm - 1:30pm (High Traffic) ==<br />
<br />
* Mark Wong<br />
* Josh Berkus<br />
<br />
== 1:30pm - 3:30pm ==<br />
<br />
* Mark Wong<br />
<br />
== 3:30pm - 4pm (High Traffic) ==<br />
<br />
* Mark Wong<br />
* Josh Berkus<br />
<br />
== 4pm - 5pm ==<br />
<br />
* Mark Wong<br />
<br />
= Saturday May 20 (8am to 5pm) =<br />
<br />
== 8am - 9:30am (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 9:30am - 10:30am ==<br />
<br />
* Mark Wong<br />
<br />
== 10:30am - 11am (High Traffic) ==<br />
<br />
* Robert Berry<br />
* Mark Wong<br />
<br />
== 11am - 12:30pm ==<br />
<br />
* Robert Berry<br />
* Mark Wong<br />
<br />
== 12:30pm - 1:30pm (High Traffic) ==<br />
<br />
* Robert Berry<br />
* Mark Wong<br />
<br />
== 1:30pm - 3:30pm ==<br />
<br />
* Mark Wong<br />
<br />
== 3:30pm - 4pm (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 4pm - 5pm ==<br />
<br />
* Mark Wong</div>Agliohttps://wiki.postgresql.org/index.php?title=PyCon_2017_Booth&diff=30161PyCon 2017 Booth2017-05-16T23:51:50Z<p>Aglio: /* 12:30pm - 1:30pm (High Traffic) */</p>
<hr />
<div>The PostgreSQL community booth at PyCon in Portland, Oregon is hosted by the Portland PostgreSQL Users Group. The dates are May 18-20 at the Oregon Convention Center. Please sign up by editing this wiki or emailing one of us before the end of the first full week of April for the t-shirt order.<br />
<br />
Contact one of us for more detail:<br />
<br />
* Gabrielle Roth <gorthx at gmail.com><br />
* Grant Holly <gdholly at gmail.com><br />
* Mark Wong <mark at 2ndQuadrant.com><br />
<br />
= Thursday May 18 (6pm to 8:30pm) - Opening Reception =<br />
<br />
* Mark Wong<br />
* Gabrielle Roth<br />
<br />
= Friday May 19 (8am to 5pm) =<br />
<br />
== 8am - 9:30am (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 9:30am - 10:30am ==<br />
<br />
* Mark Wong<br />
<br />
== 10:30am - 11am (High Traffic) ==<br />
<br />
* Mark Wong<br />
* Josh Berkus<br />
<br />
== 11am - 12:30pm ==<br />
<br />
* Mark Wong<br />
<br />
== 12:30pm - 1:30pm (High Traffic) ==<br />
<br />
* Mark Wong<br />
* Josh Berkus<br />
<br />
== 1:30pm - 3:30pm ==<br />
<br />
* Mark Wong<br />
<br />
== 3:30pm - 4pm (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 4pm - 5pm ==<br />
<br />
* Mark Wong<br />
<br />
= Saturday May 20 (8am to 5pm) =<br />
<br />
== 8am - 9:30am (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 9:30am - 10:30am ==<br />
<br />
* Mark Wong<br />
<br />
== 10:30am - 11am (High Traffic) ==<br />
<br />
* Robert Berry<br />
* Mark Wong<br />
<br />
== 11am - 12:30pm ==<br />
<br />
* Robert Berry<br />
* Mark Wong<br />
<br />
== 12:30pm - 1:30pm (High Traffic) ==<br />
<br />
* Robert Berry<br />
* Mark Wong<br />
<br />
== 1:30pm - 3:30pm ==<br />
<br />
* Mark Wong<br />
<br />
== 3:30pm - 4pm (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 4pm - 5pm ==<br />
<br />
* Mark Wong</div>Agliohttps://wiki.postgresql.org/index.php?title=PyCon_2017_Booth&diff=30160PyCon 2017 Booth2017-05-16T23:50:35Z<p>Aglio: /* 10:30am - 11am (High Traffic) */</p>
<hr />
<div>The PostgreSQL community booth at PyCon in Portland, Oregon is hosted by the Portland PostgreSQL Users Group. The dates are May 18-20 at the Oregon Convention Center. Please sign up by editing this wiki or emailing one of us before the end of the first full week of April for the t-shirt order.<br />
<br />
Contact one of us for more detail:<br />
<br />
* Gabrielle Roth <gorthx at gmail.com><br />
* Grant Holly <gdholly at gmail.com><br />
* Mark Wong <mark at 2ndQuadrant.com><br />
<br />
= Thursday May 18 (6pm to 8:30pm) - Opening Reception =<br />
<br />
* Mark Wong<br />
* Gabrielle Roth<br />
<br />
= Friday May 19 (8am to 5pm) =<br />
<br />
== 8am - 9:30am (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 9:30am - 10:30am ==<br />
<br />
* Mark Wong<br />
<br />
== 10:30am - 11am (High Traffic) ==<br />
<br />
* Mark Wong<br />
* Josh Berkus<br />
<br />
== 11am - 12:30pm ==<br />
<br />
* Mark Wong<br />
<br />
== 12:30pm - 1:30pm (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 1:30pm - 3:30pm ==<br />
<br />
* Mark Wong<br />
<br />
== 3:30pm - 4pm (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 4pm - 5pm ==<br />
<br />
* Mark Wong<br />
<br />
= Saturday May 20 (8am to 5pm) =<br />
<br />
== 8am - 9:30am (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 9:30am - 10:30am ==<br />
<br />
* Mark Wong<br />
<br />
== 10:30am - 11am (High Traffic) ==<br />
<br />
* Robert Berry<br />
* Mark Wong<br />
<br />
== 11am - 12:30pm ==<br />
<br />
* Robert Berry<br />
* Mark Wong<br />
<br />
== 12:30pm - 1:30pm (High Traffic) ==<br />
<br />
* Robert Berry<br />
* Mark Wong<br />
<br />
== 1:30pm - 3:30pm ==<br />
<br />
* Mark Wong<br />
<br />
== 3:30pm - 4pm (High Traffic) ==<br />
<br />
* Mark Wong<br />
<br />
== 4pm - 5pm ==<br />
<br />
* Mark Wong</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30158New in postgres 102017-05-16T23:00:08Z<p>Aglio: /* Drop Support for FE/BE 1.0 Protocol */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1998, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.1 ===<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30157New in postgres 102017-05-16T22:52:38Z<p>Aglio: /* Drop Support for FE/BE 1.0 Protocol */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
PostgreSQL's original [https://www.postgresql.org/docs/current/static/protocol.html client/server protocol], version 1.0, will no longer be supported as of PostgreSQL 10. Since version 1.0 was superceded by version 2.0 in 1997, it is unlikely that any existing clients still use it.<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.1 ===<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30156New in postgres 102017-05-16T22:44:58Z<p>Aglio: /* Change in Version Numbering */ version number example table</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
! Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.1 ===<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30155New in postgres 102017-05-16T22:41:11Z<p>Aglio: /* Change in Version Numbering */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
The community strongly recommends that tools use either the GUC [https://www.postgresql.org/docs/9.2/static/runtime-config-preset.html server_version_num] (on the backend), or the libpq status function [https://www.postgresql.org/docs/9.2/static/libpq-status.html PQserverVersion] in libpq to get the server version. This returns a six-digit integer version number which will be consistently sortable and comparable between versions 9.6 and 10.<br />
<br />
{|<br />
! style="text-align:left;"| Version String<br />
! Major Version<br />
! Update Number<br />
! version_num<br />
|-<br />
|9.6.0<br />
|9.6<br />
|0<br />
|090600<br />
|-<br />
|9.6.3<br />
|9.6<br />
|3<br />
|090603<br />
|-<br />
|10.0<br />
|10<br />
|0<br />
|100000<br />
|-<br />
|10.1<br />
|10<br />
|1<br />
|100001<br />
|}<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.1 ===<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30152New in postgres 102017-05-16T18:02:04Z<p>Aglio: /* Remove contrib/tsearch2 */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
Tsearch2, the older, contrib module version of our built-in full text search, has been removed from contrib and will no longer be built as part of PostgreSQL packages. Users who have been continuously upgrading since before version 8.3 will need to either manually modify their databases to use the built-in tsearch objects before upgrading to PostgreSQL 10, or will need to compile tsearch2 themselves from scratch and install it.<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.1 ===<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
=== Physical Replication ===<br />
<br />
Improved performance of the replay of 2-phase commits<br />
<br />
Improved performance of replay when access exclusive locks are held on objects on the standby server. This can significantly improve performance in cases where temporary tables are being used.<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
=== Query Planner Improvements ===<br />
<br />
In join planning, detect cases where the inner side of the join can only produce a single row for each outer side row. During execution this allows early skipping to the next outer row once a match is found. This can also remove the requirement for mark and restore during Merge Joins, which can significantly improve performance in some cases.<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30138New in postgres 102017-05-15T20:40:17Z<p>Aglio: /* Change in Version Numbering */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected.<br />
<br />
* [http://www.databasesoup.com/2016/05/changing-postgresql-version-numbering.html Changing Postgres Version Numbering]<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.1 ===<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
[https://blog.2ndquadrant.com/xmltable-intro/ XMLTABLE] is a SQL-standard feature that allows transforming an XML document to table format,<br />
making it much easier to process XML data in the database.<br />
Coupled with foreign tables pointing to external XML data, this can greatly simplify ETL processing.<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
Real-world data frequently contains correlated data in table columns, which can easily fool the query planner into thinking WHERE clauses are more selective than they really are, which can cause some queries to become very slow. [https://www.postgresql.org/docs/devel/static/sql-createstatistics.html Multivariate statistics objects] can be used to let the planner learn about this, which proofs it against making such mistakes. [https://www.postgresql.org/docs/devel/static/planner-stats.html#planner-stats-extended This manual section] explains the feature in more detail, and [https://www.postgresql.org/docs/devel/static/multivariate-statistics-examples.html this section] shows some examples.<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30135New in postgres 102017-05-15T18:33:19Z<p>Aglio: /* Backwards-Incompatible Changes */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
Version 10 has a number of backwards-incompatible changes which may affect system administration, particularly around backup automation.<br />
<br />
=== Change in Version Numbering ===<br />
<br />
As of Version 10, PostgreSQL no longer uses three-part version numbers, but is shifting to two-part version numbers. This means that version 10.1 will be the first patch update to PostgreSQL 10, ''instead of'' a new major version. Scripts and tools which detect PostgreSQL version may be affected. <br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.1 ===<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30134New in postgres 102017-05-15T17:28:18Z<p>Aglio: /* Backwards-Incompatible Changes */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
=== Change in Version Numbering ===<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
=== Drop pg_dump Support for Databases Older than 8.1 ===<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30133New in postgres 102017-05-15T17:27:37Z<p>Aglio: /* What's New In PostgreSQL 10 */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Backwards-Incompatible Changes ==<br />
<br />
=== Change in Version Numbering ===<br />
<br />
=== Renaming of "xlog" to "wal" Globally ===<br />
<br />
=== Drop Support for FE/BE 1.0 Protocol ===<br />
<br />
=== Change Defaults around Replication and pg_basebackup ===<br />
<br />
=== Drop Support for Floating Point Timestamps ===<br />
<br />
=== Remove contrib/tsearch2 ===<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30132New in postgres 102017-05-15T17:22:34Z<p>Aglio: /* Administration */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
== Administration ==<br />
<br />
=== Compression support for pg_receivewal ===<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30131New in postgres 102017-05-15T17:22:06Z<p>Aglio: /* XML and JSON */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
== Administration ==<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
=== Full Text Search support for JSON and JSONB ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30130New in postgres 102017-05-15T17:21:11Z<p>Aglio: /* Performance */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
== Administration ==<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
=== Latch Wait times in pg_stat_activity ===<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30129New in postgres 102017-05-15T17:20:37Z<p>Aglio: /* Security */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
== Administration ==<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
=== Restrictive Policies for Row Level Security ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30128New in postgres 102017-05-15T17:20:09Z<p>Aglio: /* Security */</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
== Administration ==<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
=== New "monitoring" roles for permission grants ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30127New in postgres 102017-05-15T17:00:38Z<p>Aglio: Adding more features</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
=== Faster Analytics Queries ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in libpq ===<br />
<br />
== Administration ==<br />
<br />
== SQL features ==<br />
<br />
=== Crash Safe, Replicable Hash Indexes ===<br />
<br />
=== Transition Tables for Triggers ===<br />
<br />
This feature makes AFTER STATEMENT triggers both useful and performant by<br />
exposing, as appropriate, the old and new rows to queries. Before this feature,<br />
AFTER STATEMENT triggers had no direct access to these, and the workarounds were<br />
byzantine and had poor performance. Much trigger logic can now be written as<br />
AFTER STATEMENT, avoiding the need to do the expensive context switches at each<br />
row that FOR EACH ROW triggers require.<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===<br />
<br />
== Performance ==<br />
<br />
=== Multi-column Correlation Statistics ===<br />
<br />
== Other Features ==<br />
<br />
=== ICU Collation Support ===</div>Agliohttps://wiki.postgresql.org/index.php?title=New_in_postgres_10&diff=30041New in postgres 102017-05-06T02:38:55Z<p>Aglio: Created page with "= What's New In PostgreSQL 10 = == Big Data == === Native Partitioning === == Replication and Scaling == === Logical Replication === === Quorum Commit for Synchronous Rep..."</p>
<hr />
<div>= What's New In PostgreSQL 10 =<br />
<br />
== Big Data ==<br />
<br />
=== Native Partitioning ===<br />
<br />
== Replication and Scaling ==<br />
<br />
=== Logical Replication ===<br />
<br />
=== Quorum Commit for Synchronous Replication ===<br />
<br />
=== Connection "Failover" in psql ===<br />
<br />
== Performance ==<br />
<br />
=== Additional Parallelism ===<br />
<br />
=== Additional FDW Push-Down ===<br />
<br />
== Administration ==<br />
<br />
== SQL features ==<br />
<br />
=== Transition Tables for Triggers<br />
<br />
== XML and JSON == <br />
<br />
=== XMLTable ===<br />
<br />
== Security ==<br />
<br />
=== SCRAM Authentication ===</div>Agliohttps://wiki.postgresql.org/index.php?title=SCALE15x&diff=29540SCALE15x2017-03-10T01:09:56Z<p>Aglio: /* Friday, Mar 3 */</p>
<hr />
<div>We had a two-day, two-track Postgres event at SoCal Linux Expo (SCaLE) March 2 & 3, 2017.<br />
<br />
Conference website: [http://www.socallinuxexpo.org/scale/15x SCaLE15x]<br />
<br />
Events shown for placeholding purposes. See the "Editing help" for instructions on how to add a link to your slides.<br />
<br />
== Thursday, Mar 2 ==<br />
* [http://slides.keithf4.com/managing_pg_packages/#/ Managing OS Provided PostgreSQL Packages] Keith Fiske<br />
* [https://www.slideshare.net/SeanChittenden/postgresql-zfs-best-practices PostgreSQL + ZFS: Best Practices and Standard Procedures] Sean Chittenden<br />
* [Linux IO internals for database administrators] Ilya Kosmodemiansky<br />
* [Think Your Postgres Backups and Disaster Recovery Are Safe? Let's Talk.] Payal Singh<br />
* [http://thebuild.com/presentations/securing-postgresql-scale15x.pdf Securing PostgreSQL] Christophe Pettus<br />
* [PostgreSQL snap packages, why!?] Joshua Drake<br />
* [Logical Replication in PostgreSQL] Mark Wong<br />
* [http://modernization.xformix.com/wp-content/uploads/2017/03/Scale_15x_2017.Postgresql_Modernization_Cornerstone_Case_Study_v6-1.pdf Postgresql as an Application Modernization and Consolidation Cornerstone] Charles Finley<br />
* [Amazon RDS PostgreSQL: Enabling Innovation with Cloud Managed Databases] Grant McAlister<br />
* [https://github.com/davecramer/presentations/blob/master/JDBC%20Performance%20Scale%2015x.pdf JDBC Performance Guru Tips and Tricks] Dave Cramer<br />
* [https://www.slideshare.net/AJBahnken/gophers-riding-elephants-writing-postgresql-tools-in-go Gophers Riding Elephants] AJ Bahnken<br />
* [http://www.slideshare.net/davidfetter/postgresql-hooks-for-fun-and-profit PostgreSQL Hooks for Fun and Profit] David Fetter<br />
<br />
== Friday, Mar 3 ==<br />
* [https://docs.google.com/presentation/d/13yNTDXJiZiFqyabrvc93mmHBMbLDWSHdLxWNHmgojbs/edit#slide=id.p A 30 Year History of the Postgres Project] Peter vanHardenberg<br />
* [http://www.joeconway.com/presentations/intro_to_postgresql.scale15x.pdf Intro to PostgreSQL] Joe Conway<br />
* [Becoming A SQL Guru] Stella Nisenbaum<br />
* [https://www.hagander.net/talks/PostgreSQL_9.6.pdf What's new in PostgreSQL 9.6] Magnus Hagander<br />
* [https://github.com/decibel/presentations/blob/master/CTEs.pdf How to safely use WITH in Postgres] Jim Nasby<br />
* [https://www.openscg.com/2017/03/strategic-autovacuum Strategic Autovacuum] Scott Mead<br />
* [http://jberkus.github.io/container_cluster_pg/#1 CCP: Containerized Clustered Postgres] Josh Berkus<br />
* [http://momjian.us/main/writings/pgsql/inside_shmem.pdf Inside PostgreSQL Shared Memory] Bruce Momjian<br />
* [https://www.slideshare.net/NinaKaufman4/automating-disaster-recovery-postgresql Creating a Postgres disaster recovery automation plan] Nina Kaufman<br />
* [https://docs.google.com/presentation/d/1vseuFCaOQPgoe2Qpo9-tFWfHKyyLicVGkabtl9Q5j0k/edit?usp=sharing Jaywalking in Traffic: Safe Migrations at Scale] Brad Urani<br />
* [https://www.slideshare.net/JeffFrost2/scale-15x-minimizing-postgresql-major-version-upgrade-downtime Minimizing Major Version Upgrade Downtime Utilizing Slony] [https://github.com/jfrost/scale-15x-talk scripts] Jeff Frost<br />
* [Postgres at any Scale] Will Leinweber</div>Agliohttps://wiki.postgresql.org/index.php?title=PyCon_2017_Booth&diff=29441PyCon 2017 Booth2017-02-20T23:48:06Z<p>Aglio: /* Thursday May 18 (6pm to 8:30pm) - Opening Reception */</p>
<hr />
<div>The PostgreSQL community booth at PyCon in Portland, Oregon is hosted by the Portland PostgreSQL Users Group. The dates are May 18-20 at the Oregon Convention Center. Please sign up by editing this wiki or emailing one of us before the end of the first full week of April for the t-shirt order.<br />
<br />
Contact one of us for more detail:<br />
<br />
* Gabrielle Roth <gorthx at gmail.com><br />
* Grant Holly <gdholly at gmail.com><br />
* Mark Wong <mark at 2ndQuadrant.com><br />
<br />
= Thursday May 18 (6pm to 8:30pm) - Opening Reception =<br />
<br />
* Mark Wong<br />
<br />
= Friday May 19 (8am to 5pm) =<br />
<br />
== 8am - 9:30am (High Traffic) ==<br />
<br />
== 9:30am - 10:30am ==<br />
<br />
== 10:30am - 11am (High Traffic) ==<br />
<br />
== 11am - 12:30pm ==<br />
<br />
== 12:30pm - 1:30pm (High Traffic) ==<br />
<br />
== 1:30pm - 3:30pm ==<br />
<br />
== 3:30pm - 4pm (High Traffic) ==<br />
<br />
== 4pm - 5pm ==<br />
<br />
= Saturday May 20 (8am to 5pm) =<br />
<br />
== 8am - 9:30am (High Traffic) ==<br />
<br />
== 9:30am - 10:30am ==<br />
<br />
== 10:30am - 11am (High Traffic) ==<br />
<br />
== 11am - 12:30pm ==<br />
<br />
== 12:30pm - 1:30pm (High Traffic) ==<br />
<br />
== 1:30pm - 3:30pm ==<br />
<br />
== 3:30pm - 4pm (High Traffic) ==<br />
<br />
== 4pm - 5pm ==</div>Agliohttps://wiki.postgresql.org/index.php?title=PyCon_2017_Booth&diff=29440PyCon 2017 Booth2017-02-20T23:36:19Z<p>Aglio: </p>
<hr />
<div>The PostgreSQL community booth at PyCon in Portland, Oregon is hosted by the Portland PostgreSQL Users Group. The dates are May 18-20 at the Oregon Convention Center. Please sign up by editing this wiki or emailing one of us before the end of the first full week of April for the t-shirt order.<br />
<br />
Contact one of us for more detail:<br />
<br />
* Gabrielle Roth <gorthx at gmail.com><br />
* Grant Holly <gdholly at gmail.com><br />
* Mark Wong <mark at 2ndQuadrant.com><br />
<br />
= Thursday May 18 (6pm to 8:30pm) - Opening Reception =<br />
<br />
* Mark Wong<br />
* Josh Berkus<br />
<br />
= Friday May 19 (8am to 5pm) =<br />
<br />
== 8am - 9:30am (High Traffic) ==<br />
<br />
== 9:30am - 10:30am ==<br />
<br />
== 10:30am - 11am (High Traffic) ==<br />
<br />
== 11am - 12:30pm ==<br />
<br />
== 12:30pm - 1:30pm (High Traffic) ==<br />
<br />
== 1:30pm - 3:30pm ==<br />
<br />
== 3:30pm - 4pm (High Traffic) ==<br />
<br />
== 4pm - 5pm ==<br />
<br />
= Saturday May 20 (8am to 5pm) =<br />
<br />
== 8am - 9:30am (High Traffic) ==<br />
<br />
== 9:30am - 10:30am ==<br />
<br />
== 10:30am - 11am (High Traffic) ==<br />
<br />
== 11am - 12:30pm ==<br />
<br />
== 12:30pm - 1:30pm (High Traffic) ==<br />
<br />
== 1:30pm - 3:30pm ==<br />
<br />
== 3:30pm - 4pm (High Traffic) ==<br />
<br />
== 4pm - 5pm ==</div>Agliohttps://wiki.postgresql.org/index.php?title=UpdateReleaseDrafting&diff=29177UpdateReleaseDrafting2017-01-13T00:36:08Z<p>Aglio: /* One to Two Weeks Out */</p>
<hr />
<div>= Drafting Update Releases =<br />
<br />
This is a set of guidelines for drafting update release (minor releases) announcements for PostgreSQL. <br />
<br />
There are two types of update releases: cumulative bug-fix releases, and security releases. They are distinguished by whether or not there is a CVE-worthy security vulnerability patched in the release. Depending on that, the drafting process for update release announcement is different. In order to determine which type of release you are preparing, you need to ask a member of the PostgreSQL Security Team around 2 weeks before the update release.<br />
<br />
Update releases normally happen on a Thursday, with tarballs being wrapped on an Monday. The rest of this guide assumes that this is the schedule.<br />
<br />
== Cumulative Bug-Fix Releases ==<br />
<br />
These are minor releases in which several issues are fixed, but there are no security issues big enough to warrant a CVE. Usually they come out because either (a) we're fixing a data corruption or serious crash bug, or (b) we've accumulated 3 months of bug fixes without anything else happening. Here are the steps to draft one of these releases:<br />
<br />
=== Schedule ===<br />
<br />
==== One to two weeks out ====<br />
<br />
You need to find out about the major fixes in the release:<br />
<br />
# Determine if any issues fixed in the release are urgent, such as serious data corruption bugs.<br />
# Determine if any changes in the update require action by users or special explanations, such as for backwards compatibility issues.<br />
# Determine if there are special announcements to include in the release, such as the EOL of an older version.<br />
<br />
Having determined the above, you can begin drafting the release (see below).<br />
<br />
==== Friday before the release ====<br />
<br />
* Complete the draft except for the list of miscellaneous issues fixed.<br />
* Notify the Regional Contacts that there is an update release coming, and any major issues which will be fixed in it.<br />
<br />
==== Monday of release week (US Time) ====<br />
<br />
Once that update version is branched, examine the release notes and the list of git commits in order to assemble a list of "additional bug fixes" for the release. Finish the release draft. Send links to the release draft to Hackers in order to have people double-check your descriptions and relevancy of the fix list.<br />
<br />
==== Tuesday Night or Wednesday Morning (US Time) ====<br />
<br />
* Incorporate Hacker feedback. <br />
* Produce a TXT version based on the MD release. <br />
* Check it in and let Magnus Hagander and Dave Page know that it is complete.<br />
* Send out the final version to the Regional Contacts<br />
<br />
==== Thursday Morning ====<br />
<br />
Magnus or Dave will send out the release.<br />
<br />
==== After the release ====<br />
<br />
Move the announcement to /archive/<br />
<br />
=== Release Drafting ===<br />
<br />
Update releases should be based on the "update release template" in the [https://git.postgresql.org/gitweb/?p=press.git;a=summary git.postgresql.org/press] repository. Contributors who are collaborating on the release should create a file in the update_releases/current/ subdirectory, and collaborate there. Policies for branching and/or forking are up to the contributors involved.<br />
<br />
There are two files produced for each release, a markdown file which is the version which goes on News on the website, and a Text version which is what gets sent by email. Generally it's easiest to work on the markdown version, and convert it to text when the markdown version is final.<br />
<br />
==== Urgency of Release ====<br />
<br />
We use specific language to say how quickly users need to apply a release. This is as follows:<br />
<br />
'''All users of the affected versions are strongly urged to apply the update immediately''': release contains a high-exposure security hole or critical data loss bug which affects all users. Stop reading, declare a downtime, and apply the update now. Fortunately, we've only had one of these in the last 6 years.<br />
<br />
'''All users should apply this update as soon as possible''': the release contains one or more security holes and/or major data loss bugs expected to affect most users. Schedule a downtime tonight or this weekend and apply the update.<br />
<br />
'''All users of _________ should apply this update immediately/as soon as possible''': the same as above, but only for users of a particular feature or extension.<br />
<br />
'''Users should apply this update at the next available opportunity''': the release contains some low-risk security holes and/or serious data loss bugs which only occur under certain circumstances. Updating to this release shouldn't be put off for more than a couple weeks, but you can wait for a good low-traffic window to take the downtime.<br />
<br />
'''Users should update at the next regular maintenance window/scheduled downtime''': this update contains nothing critical or even serious for most users; it's largely a cumulative collection of bugfixes. The update should be added to the general queue of OS, library and application updates for the production servers.<br />
<br />
==== Significant Fixes ====<br />
<br />
Some, but not all, bugfix releases have one or more major issues which are patched in them, and suggest a more detailed explanation for the users. Specifically:<br />
<br />
* major data corruption issues<br />
* fixes which break backwards compatibility<br />
* fixes which require post-update user action<br />
<br />
==== Bug Fix List ====<br />
<br />
Almost every release includes a list of miscellaneous bug fixes which have accumulated in the last few months. This should be a list of 40% to 70% of the fixes committed to the stable branch. What you include on this list should be significant bugs with user-visible effects, especially things which the originally affected users ought to test. You also often need to condense summary lines for these issues to that they fit on one line. See prior update releases for examples of this.<br />
<br />
==== EOL Notice ====<br />
<br />
We send out at least two notices before EOL'ing a version: one before it's EOL, letting people know that the next update will be the last, and one when it is EOL, letting users know that this is the very last update for that version.<br />
<br />
== Security Releases ==<br />
<br />
Security releases are ones which contain a fix for one or more security issues sufficient to warrant a CVE.<br />
<br />
Because of this security fix information, we cannot use a public process for drafting the release. <br />
<br />
Aside from that, most of the process of creating a security release is the same as for creating a regular update release. Below are the parts which are different, otherwise refer to Update Releases above.<br />
<br />
=== Templates ===<br />
<br />
Use the [https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/templates/security_release_template.md security release] template.<br />
<br />
=== Choosing Release Writers ===<br />
<br />
Two weeks before the release, the Release Committee will solicit two writers to work on the release:<br />
<br />
* A PR writer from the Advocacy group<br />
* A security expert from the Security group<br />
<br />
The PR writer will need to be a community member of proven discretion, but need not be a member of the Security Team.<br />
<br />
=== One to Two Weeks Out ===<br />
<br />
The Security team member will contact the PR Writer with notes about the fixed security releases. The PR Writer will work with the security team member to get those issues summarized succinctly but accurately. This work will be done by email and/or secure, private collaboration mechanisms (but not via git.postgresql.org).<br />
<br />
Unlike regular update releases, the PR Writer may not share the full text of the release on pgsql-hackers to look for more information about included patches. Instead, they should share only the patch list, excluding any of the security patches.<br />
<br />
=== Friday before the Release ===<br />
<br />
You may notify RCs that a release is coming, but not its contents.<br />
<br />
=== Three Days Out (Monday) ===<br />
<br />
At this point the fixes for the security release should be committed to git, and we should have final text for the CVEs:<br />
<br />
* The Security Team member will share the CVE numbers and text with the PR Writer<br />
* The PR Writer can finalize text check his draft announcement into git.postgresql.org/press<br />
* The PR Writer will create a patch for the website to update the [https://www.postgresql.org/support/security/ Security Page]<br />
* The PR Writer can share the draft release with the Regional Contacts<br />
<br />
The patch for the Security Page should list out all CVEs and their associated information in the existing format. This patch will be submitted to the Web Team for review, as well as to the Security Team member for checking the security information.<br />
<br />
=== Follow-ups ===<br />
<br />
One week after the release, if a version of PostgreSQL is now newly EOL, the PR Writer should create a patch to move all of the security issues associated with the EOL release only to the [https://www.postgresql.org/support/security_archive/ Security Archive Page].<br />
<br />
= Links =<br />
<br />
* [https://www.postgresql.org/about/press/contact/ List of Regional Contacts]<br />
* [https://wiki.postgresql.org/wiki/HowToRC How to be a Regional Contact]</div>Agliohttps://wiki.postgresql.org/index.php?title=UpdateReleaseDrafting&diff=29176UpdateReleaseDrafting2017-01-13T00:35:21Z<p>Aglio: /* Security Releases */ added security release procedure</p>
<hr />
<div>= Drafting Update Releases =<br />
<br />
This is a set of guidelines for drafting update release (minor releases) announcements for PostgreSQL. <br />
<br />
There are two types of update releases: cumulative bug-fix releases, and security releases. They are distinguished by whether or not there is a CVE-worthy security vulnerability patched in the release. Depending on that, the drafting process for update release announcement is different. In order to determine which type of release you are preparing, you need to ask a member of the PostgreSQL Security Team around 2 weeks before the update release.<br />
<br />
Update releases normally happen on a Thursday, with tarballs being wrapped on an Monday. The rest of this guide assumes that this is the schedule.<br />
<br />
== Cumulative Bug-Fix Releases ==<br />
<br />
These are minor releases in which several issues are fixed, but there are no security issues big enough to warrant a CVE. Usually they come out because either (a) we're fixing a data corruption or serious crash bug, or (b) we've accumulated 3 months of bug fixes without anything else happening. Here are the steps to draft one of these releases:<br />
<br />
=== Schedule ===<br />
<br />
==== One to two weeks out ====<br />
<br />
You need to find out about the major fixes in the release:<br />
<br />
# Determine if any issues fixed in the release are urgent, such as serious data corruption bugs.<br />
# Determine if any changes in the update require action by users or special explanations, such as for backwards compatibility issues.<br />
# Determine if there are special announcements to include in the release, such as the EOL of an older version.<br />
<br />
Having determined the above, you can begin drafting the release (see below).<br />
<br />
==== Friday before the release ====<br />
<br />
* Complete the draft except for the list of miscellaneous issues fixed.<br />
* Notify the Regional Contacts that there is an update release coming, and any major issues which will be fixed in it.<br />
<br />
==== Monday of release week (US Time) ====<br />
<br />
Once that update version is branched, examine the release notes and the list of git commits in order to assemble a list of "additional bug fixes" for the release. Finish the release draft. Send links to the release draft to Hackers in order to have people double-check your descriptions and relevancy of the fix list.<br />
<br />
==== Tuesday Night or Wednesday Morning (US Time) ====<br />
<br />
* Incorporate Hacker feedback. <br />
* Produce a TXT version based on the MD release. <br />
* Check it in and let Magnus Hagander and Dave Page know that it is complete.<br />
* Send out the final version to the Regional Contacts<br />
<br />
==== Thursday Morning ====<br />
<br />
Magnus or Dave will send out the release.<br />
<br />
==== After the release ====<br />
<br />
Move the announcement to /archive/<br />
<br />
=== Release Drafting ===<br />
<br />
Update releases should be based on the "update release template" in the [https://git.postgresql.org/gitweb/?p=press.git;a=summary git.postgresql.org/press] repository. Contributors who are collaborating on the release should create a file in the update_releases/current/ subdirectory, and collaborate there. Policies for branching and/or forking are up to the contributors involved.<br />
<br />
There are two files produced for each release, a markdown file which is the version which goes on News on the website, and a Text version which is what gets sent by email. Generally it's easiest to work on the markdown version, and convert it to text when the markdown version is final.<br />
<br />
==== Urgency of Release ====<br />
<br />
We use specific language to say how quickly users need to apply a release. This is as follows:<br />
<br />
'''All users of the affected versions are strongly urged to apply the update immediately''': release contains a high-exposure security hole or critical data loss bug which affects all users. Stop reading, declare a downtime, and apply the update now. Fortunately, we've only had one of these in the last 6 years.<br />
<br />
'''All users should apply this update as soon as possible''': the release contains one or more security holes and/or major data loss bugs expected to affect most users. Schedule a downtime tonight or this weekend and apply the update.<br />
<br />
'''All users of _________ should apply this update immediately/as soon as possible''': the same as above, but only for users of a particular feature or extension.<br />
<br />
'''Users should apply this update at the next available opportunity''': the release contains some low-risk security holes and/or serious data loss bugs which only occur under certain circumstances. Updating to this release shouldn't be put off for more than a couple weeks, but you can wait for a good low-traffic window to take the downtime.<br />
<br />
'''Users should update at the next regular maintenance window/scheduled downtime''': this update contains nothing critical or even serious for most users; it's largely a cumulative collection of bugfixes. The update should be added to the general queue of OS, library and application updates for the production servers.<br />
<br />
==== Significant Fixes ====<br />
<br />
Some, but not all, bugfix releases have one or more major issues which are patched in them, and suggest a more detailed explanation for the users. Specifically:<br />
<br />
* major data corruption issues<br />
* fixes which break backwards compatibility<br />
* fixes which require post-update user action<br />
<br />
==== Bug Fix List ====<br />
<br />
Almost every release includes a list of miscellaneous bug fixes which have accumulated in the last few months. This should be a list of 40% to 70% of the fixes committed to the stable branch. What you include on this list should be significant bugs with user-visible effects, especially things which the originally affected users ought to test. You also often need to condense summary lines for these issues to that they fit on one line. See prior update releases for examples of this.<br />
<br />
==== EOL Notice ====<br />
<br />
We send out at least two notices before EOL'ing a version: one before it's EOL, letting people know that the next update will be the last, and one when it is EOL, letting users know that this is the very last update for that version.<br />
<br />
== Security Releases ==<br />
<br />
Security releases are ones which contain a fix for one or more security issues sufficient to warrant a CVE.<br />
<br />
Because of this security fix information, we cannot use a public process for drafting the release. <br />
<br />
Aside from that, most of the process of creating a security release is the same as for creating a regular update release. Below are the parts which are different, otherwise refer to Update Releases above.<br />
<br />
=== Templates ===<br />
<br />
Use the [https://git.postgresql.org/gitweb/?p=press.git;a=blob;f=update_releases/templates/security_release_template.md security release] template.<br />
<br />
=== Choosing Release Writers ===<br />
<br />
Two weeks before the release, the Release Committee will solicit two writers to work on the release:<br />
<br />
* A PR writer from the Advocacy group<br />
* A security expert from the Security group<br />
<br />
The PR writer will need to be a community member of proven discretion, but need not be a member of the Security Team.<br />
<br />
=== One to Two Weeks Out ===<br />
<br />
The Security team member will contact the PR Writer with notes about the fixed security releases. The PR Writer will work with the security team member to get those issues summarized succinctly but accurately. This work will be done by email and/or secure, private collaboration mechanisms (but not via git.postgresql.org).<br />
<br />
Unlike regular update releases, the PR Writer may not share the full text of the release on pgsql-hackers to look for more information about included patches. Instead, they should share only the patch list.<br />
<br />
=== Friday before the Release ===<br />
<br />
You may notify RCs that a release is coming, but not its contents.<br />
<br />
=== Three Days Out (Monday) ===<br />
<br />
At this point the fixes for the security release should be committed to git, and we should have final text for the CVEs:<br />
<br />
* The Security Team member will share the CVE numbers and text with the PR Writer<br />
* The PR Writer can finalize text check his draft announcement into git.postgresql.org/press<br />
* The PR Writer will create a patch for the website to update the [https://www.postgresql.org/support/security/ Security Page]<br />
* The PR Writer can share the draft release with the Regional Contacts<br />
<br />
The patch for the Security Page should list out all CVEs and their associated information in the existing format. This patch will be submitted to the Web Team for review, as well as to the Security Team member for checking the security information.<br />
<br />
=== Follow-ups ===<br />
<br />
One week after the release, if a version of PostgreSQL is now newly EOL, the PR Writer should create a patch to move all of the security issues associated with the EOL release only to the [https://www.postgresql.org/support/security_archive/ Security Archive Page].<br />
<br />
= Links =<br />
<br />
* [https://www.postgresql.org/about/press/contact/ List of Regional Contacts]<br />
* [https://wiki.postgresql.org/wiki/HowToRC How to be a Regional Contact]</div>Agliohttps://wiki.postgresql.org/index.php?title=UpdateReleaseDrafting&diff=28354UpdateReleaseDrafting2016-10-17T21:31:21Z<p>Aglio: /* Release Drafting */</p>
<hr />
<div>= Drafting Update Releases =<br />
<br />
This is a set of guidelines for drafting update release (minor releases) announcements for PostgreSQL. <br />
<br />
There are two types of update releases: cumulative bug-fix releases, and security releases. They are distinguished by whether or not there is a CVE-worthy security vulnerability patched in the release. Depending on that, the drafting process for update release announcement is different. In order to determine which type of release you are preparing, you need to ask a member of the PostgreSQL Security Team around 2 weeks before the update release.<br />
<br />
Update releases normally happen on a Thursday, with tarballs being wrapped on an Monday. The rest of this guide assumes that this is the schedule.<br />
<br />
== Cumulative Bug-Fix Releases ==<br />
<br />
These are minor releases in which several issues are fixed, but there are no security issues big enough to warrant a CVE. Usually they come out because either (a) we're fixing a data corruption or serious crash bug, or (b) we've accumulated 3 months of bug fixes without anything else happening. Here are the steps to draft one of these releases:<br />
<br />
=== Schedule ===<br />
<br />
==== One to two weeks out ====<br />
<br />
You need to find out about the major fixes in the release:<br />
<br />
# Determine if any issues fixed in the release are urgent, such as serious data corruption bugs.<br />
# Determine if any changes in the update require action by users or special explanations, such as for backwards compatibility issues.<br />
# Determine if there are special announcements to include in the release, such as the EOL of an older version.<br />
<br />
Having determined the above, you can begin drafting the release (see below).<br />
<br />
==== Friday before the release ====<br />
<br />
* Complete the draft except for the list of miscellaneous issues fixed.<br />
* Notify the Regional Contacts that there is an update release coming, and any major issues which will be fixed in it.<br />
<br />
==== Monday of release week (US Time) ====<br />
<br />
Once that update version is branched, examine the release notes and the list of git commits in order to assemble a list of "additional bug fixes" for the release. Finish the release draft. Send links to the release draft to Hackers in order to have people double-check your descriptions and relevancy of the fix list.<br />
<br />
==== Tuesday Night or Wednesday Morning (US Time) ====<br />
<br />
* Incorporate Hacker feedback. <br />
* Produce a TXT version based on the MD release. <br />
* Check it in and let Magnus Hagander and Dave Page know that it is complete.<br />
* Send out the final version to the Regional Contacts<br />
<br />
==== Thursday Morning ====<br />
<br />
Magnus or Dave will send out the release.<br />
<br />
==== After the release ====<br />
<br />
Move the announcement to /archive/<br />
<br />
=== Release Drafting ===<br />
<br />
Update releases should be based on the "update release template" in the [https://git.postgresql.org/gitweb/?p=press.git;a=summary git.postgresql.org/press] repository. Contributors who are collaborating on the release should create a file in the update_releases/current/ subdirectory, and collaborate there. Policies for branching and/or forking are up to the contributors involved.<br />
<br />
There are two files produced for each release, a markdown file which is the version which goes on News on the website, and a Text version which is what gets sent by email. Generally it's easiest to work on the markdown version, and convert it to text when the markdown version is final.<br />
<br />
==== Urgency of Release ====<br />
<br />
We use specific language to say how quickly users need to apply a release. This is as follows:<br />
<br />
'''All users of the affected versions are strongly urged to apply the update immediately''': release contains a high-exposure security hole or critical data loss bug which affects all users. Stop reading, declare a downtime, and apply the update now. Fortunately, we've only had one of these in the last 6 years.<br />
<br />
'''All users should apply this update as soon as possible''': the release contains one or more security holes and/or major data loss bugs expected to affect most users. Schedule a downtime tonight or this weekend and apply the update.<br />
<br />
'''All users of _________ should apply this update immediately/as soon as possible''': the same as above, but only for users of a particular feature or extension.<br />
<br />
'''Users should apply this update at the next available opportunity''': the release contains some low-risk security holes and/or serious data loss bugs which only occur under certain circumstances. Updating to this release shouldn't be put off for more than a couple weeks, but you can wait for a good low-traffic window to take the downtime.<br />
<br />
'''Users should update at the next regular maintenance window/scheduled downtime''': this update contains nothing critical or even serious for most users; it's largely a cumulative collection of bugfixes. The update should be added to the general queue of OS, library and application updates for the production servers.<br />
<br />
==== Significant Fixes ====<br />
<br />
Some, but not all, bugfix releases have one or more major issues which are patched in them, and suggest a more detailed explanation for the users. Specifically:<br />
<br />
* major data corruption issues<br />
* fixes which break backwards compatibility<br />
* fixes which require post-update user action<br />
<br />
==== Bug Fix List ====<br />
<br />
Almost every release includes a list of miscellaneous bug fixes which have accumulated in the last few months. This should be a list of 40% to 70% of the fixes committed to the stable branch. What you include on this list should be significant bugs with user-visible effects, especially things which the originally affected users ought to test. You also often need to condense summary lines for these issues to that they fit on one line. See prior update releases for examples of this.<br />
<br />
==== EOL Notice ====<br />
<br />
We send out at least two notices before EOL'ing a version: one before it's EOL, letting people know that the next update will be the last, and one when it is EOL, letting users know that this is the very last update for that version.<br />
<br />
== Security Releases ==<br />
<br />
TBD</div>Agliohttps://wiki.postgresql.org/index.php?title=UpdateReleaseDrafting&diff=28352UpdateReleaseDrafting2016-10-17T21:30:08Z<p>Aglio: /* Thursday Morning */</p>
<hr />
<div>= Drafting Update Releases =<br />
<br />
This is a set of guidelines for drafting update release (minor releases) announcements for PostgreSQL. <br />
<br />
There are two types of update releases: cumulative bug-fix releases, and security releases. They are distinguished by whether or not there is a CVE-worthy security vulnerability patched in the release. Depending on that, the drafting process for update release announcement is different. In order to determine which type of release you are preparing, you need to ask a member of the PostgreSQL Security Team around 2 weeks before the update release.<br />
<br />
Update releases normally happen on a Thursday, with tarballs being wrapped on an Monday. The rest of this guide assumes that this is the schedule.<br />
<br />
== Cumulative Bug-Fix Releases ==<br />
<br />
These are minor releases in which several issues are fixed, but there are no security issues big enough to warrant a CVE. Usually they come out because either (a) we're fixing a data corruption or serious crash bug, or (b) we've accumulated 3 months of bug fixes without anything else happening. Here are the steps to draft one of these releases:<br />
<br />
=== Schedule ===<br />
<br />
==== One to two weeks out ====<br />
<br />
You need to find out about the major fixes in the release:<br />
<br />
1. Determine if any issues fixed in the release are urgent, such as serious data corruption bugs.<br />
2. Determine if any changes in the update require action by users or special explanations, such as for backwards compatibility issues.<br />
3. Determine if there are special announcements to include in the release, such as the EOL of an older version.<br />
<br />
Having determined the above, you can begin drafting the release (see below).<br />
<br />
==== Friday before the release ====<br />
<br />
* Complete the draft except for the list of miscellaneous issues fixed.<br />
* Notify the Regional Contacts that there is an update release coming, and any major issues which will be fixed in it.<br />
<br />
==== Monday of release week (US Time) ====<br />
<br />
Once that update version is branched, examine the release notes and the list of git commits in order to assemble a list of "additional bug fixes" for the release. Finish the release draft. Send links to the release draft to Hackers in order to have people double-check your descriptions and relevancy of the fix list.<br />
<br />
==== Tuesday Night or Wednesday Morning (US Time) ====<br />
<br />
* Incorporate Hacker feedback. <br />
* Produce a TXT version based on the MD release. <br />
* Check it in and let Magnus Hagander and Dave Page know that it is complete.<br />
* Send out the final version to the Regional Contacts<br />
<br />
==== Thursday Morning ====<br />
<br />
Magnus or Dave will send out the release.<br />
<br />
==== After the release ====<br />
<br />
Move the announcement to /archive/<br />
<br />
=== Release Drafting ===<br />
<br />
Update releases should be based on the "update release template" in the [https://git.postgresql.org/gitweb/?p=press.git;a=summary git.postgresql.org/press] repository. Contributors who are collaborating on the release should create a file in the update_releases/current/ subdirectory, and collaborate there. Policies for branching and/or forking are up to the contributors involved.<br />
<br />
==== Urgency of Release ====<br />
<br />
We use specific language to say how quickly users need to apply a release. This is as follows:<br />
<br />
'''All users of the affected versions are strongly urged to apply the update immediately''': release contains a high-exposure security hole or critical data loss bug which affects all users. Stop reading, declare a downtime, and apply the update now. Fortunately, we've only had one of these in the last 6 years.<br />
<br />
'''All users should apply this update as soon as possible''': the release contains one or more security holes and/or major data loss bugs expected to affect most users. Schedule a downtime tonight or this weekend and apply the update.<br />
<br />
'''All users of _________ should apply this update immediately/as soon as possible''': the same as above, but only for users of a particular feature or extension.<br />
<br />
'''Users should apply this update at the next available opportunity''': the release contains some low-risk security holes and/or serious data loss bugs which only occur under certain circumstances. Updating to this release shouldn't be put off for more than a couple weeks, but you can wait for a good low-traffic window to take the downtime.<br />
<br />
'''Users should update at the next regular maintenance window/scheduled downtime''': this update contains nothing critical or even serious for most users; it's largely a cumulative collection of bugfixes. The update should be added to the general queue of OS, library and application updates for the production servers.<br />
<br />
==== Significant Fixes ====<br />
<br />
Some, but not all, bugfix releases have one or more major issues which are patched in them, and suggest a more detailed explanation for the users. Specifically:<br />
<br />
* major data corruption issues<br />
* fixes which break backwards compatibility<br />
* fixes which require post-update user action<br />
<br />
==== Bug Fix List ====<br />
<br />
Almost every release includes a list of miscellaneous bug fixes which have accumulated in the last few months. This should be a list of 40% to 70% of the fixes committed to the stable branch. What you include on this list should be significant bugs with user-visible effects, especially things which the originally affected users ought to test. You also often need to condense summary lines for these issues to that they fit on one line. See prior update releases for examples of this.<br />
<br />
==== EOL Notice ====<br />
<br />
We send out at least two notices before EOL'ing a version: one before it's EOL, letting people know that the next update will be the last, and one when it is EOL, letting users know that this is the very last update for that version.<br />
<br />
== Security Releases ==<br />
<br />
TBD</div>Agliohttps://wiki.postgresql.org/index.php?title=UpdateReleaseDrafting&diff=28351UpdateReleaseDrafting2016-10-17T21:28:37Z<p>Aglio: /* = Tuesday Night or Wednesday Morning (US Time) */</p>
<hr />
<div>= Drafting Update Releases =<br />
<br />
This is a set of guidelines for drafting update release (minor releases) announcements for PostgreSQL. <br />
<br />
There are two types of update releases: cumulative bug-fix releases, and security releases. They are distinguished by whether or not there is a CVE-worthy security vulnerability patched in the release. Depending on that, the drafting process for update release announcement is different. In order to determine which type of release you are preparing, you need to ask a member of the PostgreSQL Security Team around 2 weeks before the update release.<br />
<br />
Update releases normally happen on a Thursday, with tarballs being wrapped on an Monday. The rest of this guide assumes that this is the schedule.<br />
<br />
== Cumulative Bug-Fix Releases ==<br />
<br />
These are minor releases in which several issues are fixed, but there are no security issues big enough to warrant a CVE. Usually they come out because either (a) we're fixing a data corruption or serious crash bug, or (b) we've accumulated 3 months of bug fixes without anything else happening. Here are the steps to draft one of these releases:<br />
<br />
=== Schedule ===<br />
<br />
==== One to two weeks out ====<br />
<br />
You need to find out about the major fixes in the release:<br />
<br />
1. Determine if any issues fixed in the release are urgent, such as serious data corruption bugs.<br />
2. Determine if any changes in the update require action by users or special explanations, such as for backwards compatibility issues.<br />
3. Determine if there are special announcements to include in the release, such as the EOL of an older version.<br />
<br />
Having determined the above, you can begin drafting the release (see below).<br />
<br />
==== Friday before the release ====<br />
<br />
* Complete the draft except for the list of miscellaneous issues fixed.<br />
* Notify the Regional Contacts that there is an update release coming, and any major issues which will be fixed in it.<br />
<br />
==== Monday of release week (US Time) ====<br />
<br />
Once that update version is branched, examine the release notes and the list of git commits in order to assemble a list of "additional bug fixes" for the release. Finish the release draft. Send links to the release draft to Hackers in order to have people double-check your descriptions and relevancy of the fix list.<br />
<br />
==== Tuesday Night or Wednesday Morning (US Time) ====<br />
<br />
* Incorporate Hacker feedback. <br />
* Produce a TXT version based on the MD release. <br />
* Check it in and let Magnus Hagander and Dave Page know that it is complete.<br />
* Send out the final version to the Regional Contacts<br />
<br />
==== Thursday Morning ====<br />
<br />
Magnus or Dave will send out the release.<br />
<br />
=== Release Drafting ===<br />
<br />
Update releases should be based on the "update release template" in the [https://git.postgresql.org/gitweb/?p=press.git;a=summary git.postgresql.org/press] repository. Contributors who are collaborating on the release should create a file in the update_releases/current/ subdirectory, and collaborate there. Policies for branching and/or forking are up to the contributors involved.<br />
<br />
==== Urgency of Release ====<br />
<br />
We use specific language to say how quickly users need to apply a release. This is as follows:<br />
<br />
'''All users of the affected versions are strongly urged to apply the update immediately''': release contains a high-exposure security hole or critical data loss bug which affects all users. Stop reading, declare a downtime, and apply the update now. Fortunately, we've only had one of these in the last 6 years.<br />
<br />
'''All users should apply this update as soon as possible''': the release contains one or more security holes and/or major data loss bugs expected to affect most users. Schedule a downtime tonight or this weekend and apply the update.<br />
<br />
'''All users of _________ should apply this update immediately/as soon as possible''': the same as above, but only for users of a particular feature or extension.<br />
<br />
'''Users should apply this update at the next available opportunity''': the release contains some low-risk security holes and/or serious data loss bugs which only occur under certain circumstances. Updating to this release shouldn't be put off for more than a couple weeks, but you can wait for a good low-traffic window to take the downtime.<br />
<br />
'''Users should update at the next regular maintenance window/scheduled downtime''': this update contains nothing critical or even serious for most users; it's largely a cumulative collection of bugfixes. The update should be added to the general queue of OS, library and application updates for the production servers.<br />
<br />
==== Significant Fixes ====<br />
<br />
Some, but not all, bugfix releases have one or more major issues which are patched in them, and suggest a more detailed explanation for the users. Specifically:<br />
<br />
* major data corruption issues<br />
* fixes which break backwards compatibility<br />
* fixes which require post-update user action<br />
<br />
==== Bug Fix List ====<br />
<br />
Almost every release includes a list of miscellaneous bug fixes which have accumulated in the last few months. This should be a list of 40% to 70% of the fixes committed to the stable branch. What you include on this list should be significant bugs with user-visible effects, especially things which the originally affected users ought to test. You also often need to condense summary lines for these issues to that they fit on one line. See prior update releases for examples of this.<br />
<br />
==== EOL Notice ====<br />
<br />
We send out at least two notices before EOL'ing a version: one before it's EOL, letting people know that the next update will be the last, and one when it is EOL, letting users know that this is the very last update for that version.<br />
<br />
== Security Releases ==<br />
<br />
TBD</div>Agliohttps://wiki.postgresql.org/index.php?title=UpdateReleaseDrafting&diff=28350UpdateReleaseDrafting2016-10-17T21:26:01Z<p>Aglio: /* Urgency of Release */</p>
<hr />
<div>= Drafting Update Releases =<br />
<br />
This is a set of guidelines for drafting update release (minor releases) announcements for PostgreSQL. <br />
<br />
There are two types of update releases: cumulative bug-fix releases, and security releases. They are distinguished by whether or not there is a CVE-worthy security vulnerability patched in the release. Depending on that, the drafting process for update release announcement is different. In order to determine which type of release you are preparing, you need to ask a member of the PostgreSQL Security Team around 2 weeks before the update release.<br />
<br />
Update releases normally happen on a Thursday, with tarballs being wrapped on an Monday. The rest of this guide assumes that this is the schedule.<br />
<br />
== Cumulative Bug-Fix Releases ==<br />
<br />
These are minor releases in which several issues are fixed, but there are no security issues big enough to warrant a CVE. Usually they come out because either (a) we're fixing a data corruption or serious crash bug, or (b) we've accumulated 3 months of bug fixes without anything else happening. Here are the steps to draft one of these releases:<br />
<br />
=== Schedule ===<br />
<br />
==== One to two weeks out ====<br />
<br />
You need to find out about the major fixes in the release:<br />
<br />
1. Determine if any issues fixed in the release are urgent, such as serious data corruption bugs.<br />
2. Determine if any changes in the update require action by users or special explanations, such as for backwards compatibility issues.<br />
3. Determine if there are special announcements to include in the release, such as the EOL of an older version.<br />
<br />
Having determined the above, you can begin drafting the release (see below).<br />
<br />
==== Friday before the release ====<br />
<br />
* Complete the draft except for the list of miscellaneous issues fixed.<br />
* Notify the Regional Contacts that there is an update release coming, and any major issues which will be fixed in it.<br />
<br />
==== Monday of release week (US Time) ====<br />
<br />
Once that update version is branched, examine the release notes and the list of git commits in order to assemble a list of "additional bug fixes" for the release. Finish the release draft. Send links to the release draft to Hackers in order to have people double-check your descriptions and relevancy of the fix list.<br />
<br />
==== Tuesday Night or Wednesday Morning (US Time) ===<br />
<br />
* Incorporate Hacker feedback. <br />
* Produce a TXT version based on the MD release. <br />
* Check it in and let Magnus Hagander and Dave Page know that it is complete.<br />
* Send out the final version to the Regional Contacts<br />
<br />
==== Thursday Morning ====<br />
<br />
Magnus or Dave will send out the release.<br />
<br />
=== Release Drafting ===<br />
<br />
Update releases should be based on the "update release template" in the [https://git.postgresql.org/gitweb/?p=press.git;a=summary git.postgresql.org/press] repository. Contributors who are collaborating on the release should create a file in the update_releases/current/ subdirectory, and collaborate there. Policies for branching and/or forking are up to the contributors involved.<br />
<br />
==== Urgency of Release ====<br />
<br />
We use specific language to say how quickly users need to apply a release. This is as follows:<br />
<br />
'''All users of the affected versions are strongly urged to apply the update immediately''': release contains a high-exposure security hole or critical data loss bug which affects all users. Stop reading, declare a downtime, and apply the update now. Fortunately, we've only had one of these in the last 6 years.<br />
<br />
'''All users should apply this update as soon as possible''': the release contains one or more security holes and/or major data loss bugs expected to affect most users. Schedule a downtime tonight or this weekend and apply the update.<br />
<br />
'''All users of _________ should apply this update immediately/as soon as possible''': the same as above, but only for users of a particular feature or extension.<br />
<br />
'''Users should apply this update at the next available opportunity''': the release contains some low-risk security holes and/or serious data loss bugs which only occur under certain circumstances. Updating to this release shouldn't be put off for more than a couple weeks, but you can wait for a good low-traffic window to take the downtime.<br />
<br />
'''Users should update at the next regular maintenance window/scheduled downtime''': this update contains nothing critical or even serious for most users; it's largely a cumulative collection of bugfixes. The update should be added to the general queue of OS, library and application updates for the production servers.<br />
<br />
==== Significant Fixes ====<br />
<br />
Some, but not all, bugfix releases have one or more major issues which are patched in them, and suggest a more detailed explanation for the users. Specifically:<br />
<br />
* major data corruption issues<br />
* fixes which break backwards compatibility<br />
* fixes which require post-update user action<br />
<br />
==== Bug Fix List ====<br />
<br />
Almost every release includes a list of miscellaneous bug fixes which have accumulated in the last few months. This should be a list of 40% to 70% of the fixes committed to the stable branch. What you include on this list should be significant bugs with user-visible effects, especially things which the originally affected users ought to test. You also often need to condense summary lines for these issues to that they fit on one line. See prior update releases for examples of this.<br />
<br />
==== EOL Notice ====<br />
<br />
We send out at least two notices before EOL'ing a version: one before it's EOL, letting people know that the next update will be the last, and one when it is EOL, letting users know that this is the very last update for that version.<br />
<br />
== Security Releases ==<br />
<br />
TBD</div>Agliohttps://wiki.postgresql.org/index.php?title=UpdateReleaseDrafting&diff=28349UpdateReleaseDrafting2016-10-17T21:19:20Z<p>Aglio: Created page with "= Drafting Update Releases = This is a set of guidelines for drafting update release (minor releases) announcements for PostgreSQL. There are two types of update releases:..."</p>
<hr />
<div>= Drafting Update Releases =<br />
<br />
This is a set of guidelines for drafting update release (minor releases) announcements for PostgreSQL. <br />
<br />
There are two types of update releases: cumulative bug-fix releases, and security releases. They are distinguished by whether or not there is a CVE-worthy security vulnerability patched in the release. Depending on that, the drafting process for update release announcement is different. In order to determine which type of release you are preparing, you need to ask a member of the PostgreSQL Security Team around 2 weeks before the update release.<br />
<br />
Update releases normally happen on a Thursday, with tarballs being wrapped on an Monday. The rest of this guide assumes that this is the schedule.<br />
<br />
== Cumulative Bug-Fix Releases ==<br />
<br />
These are minor releases in which several issues are fixed, but there are no security issues big enough to warrant a CVE. Usually they come out because either (a) we're fixing a data corruption or serious crash bug, or (b) we've accumulated 3 months of bug fixes without anything else happening. Here are the steps to draft one of these releases:<br />
<br />
=== Schedule ===<br />
<br />
==== One to two weeks out ====<br />
<br />
You need to find out about the major fixes in the release:<br />
<br />
1. Determine if any issues fixed in the release are urgent, such as serious data corruption bugs.<br />
2. Determine if any changes in the update require action by users or special explanations, such as for backwards compatibility issues.<br />
3. Determine if there are special announcements to include in the release, such as the EOL of an older version.<br />
<br />
Having determined the above, you can begin drafting the release (see below).<br />
<br />
==== Friday before the release ====<br />
<br />
* Complete the draft except for the list of miscellaneous issues fixed.<br />
* Notify the Regional Contacts that there is an update release coming, and any major issues which will be fixed in it.<br />
<br />
==== Monday of release week (US Time) ====<br />
<br />
Once that update version is branched, examine the release notes and the list of git commits in order to assemble a list of "additional bug fixes" for the release. Finish the release draft. Send links to the release draft to Hackers in order to have people double-check your descriptions and relevancy of the fix list.<br />
<br />
==== Tuesday Night or Wednesday Morning (US Time) ===<br />
<br />
* Incorporate Hacker feedback. <br />
* Produce a TXT version based on the MD release. <br />
* Check it in and let Magnus Hagander and Dave Page know that it is complete.<br />
* Send out the final version to the Regional Contacts<br />
<br />
==== Thursday Morning ====<br />
<br />
Magnus or Dave will send out the release.<br />
<br />
=== Release Drafting ===<br />
<br />
Update releases should be based on the "update release template" in the [https://git.postgresql.org/gitweb/?p=press.git;a=summary git.postgresql.org/press] repository. Contributors who are collaborating on the release should create a file in the update_releases/current/ subdirectory, and collaborate there. Policies for branching and/or forking are up to the contributors involved.<br />
<br />
==== Urgency of Release ====<br />
<br />
We use specific language to say how quickly users need to apply a release. This is as follows:<br />
<br />
<br />
<br />
<br />
<br />
== Security Releases ==<br />
<br />
TBD</div>Agliohttps://wiki.postgresql.org/index.php?title=NewIn96&diff=28271NewIn962016-09-28T18:49:52Z<p>Aglio: </p>
<hr />
<div>= What's New in PostgreSQL 9.6 =<br />
<br />
This page is a work in progress which will include details of PostgreSQL 9.6 features and changes. Many thanks to Thom Brown for assembling the original list.<br />
<br />
== Parallel Query ==<br />
<br />
=== Parallel sequential scans ===<br />
<br />
PostgreSQL can now execute a full table scan in multiple parallel processes, up to the limits set by the user.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZwVzN-0000Xz-5e@gemulon.postgresql.org Generate parallel sequential scan plans in simple cases. ]<br />
* [https://www.depesz.com/2015/11/17/waiting-for-9-6-generate-parallel-sequential-scan-plans-in-simple-cases/ Waiting for 9.6 – Generate parallel sequential scan plans in simple cases.]<br />
* [https://lwn.net/Articles/689387/ pgCon and PostgreSQL 9.6]<br />
<br />
=== parallel joins ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aLyct-000314-UZ@gemulon.postgresql.org Support parallel joins, and make related improvements. ]<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-support-parallel-joins-and-make-related-improvements/ Waiting for 9.6 – Support parallel joins, and make related improvements.]<br />
<br />
=== parallel aggregates ===<br />
<br />
Parallel Aggregates allow aggregate functions to be processed concurrently by multiple worker processes. This can significantly increase the response times for queries aggregating large amounts of tuples down to just a few aggregate groups, providing that the server has enough otherwise idle CPUs and would otherwise be bounded by the single CPU which the backend process is running on. Each worker process operates on a subset of tuples and creates a partially aggregated result to which it returns to the main backend process where each partial result will be combined with ones from the other worker processes and the final aggregate result produced.<br />
<br />
Most internal aggregate functions support parallel mode. User defined aggregates will need to be changed to add a combine function, and possible a serialization and deserialization in the case of aggregate functions which return an INTERNAL state.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ahzxY-0004qA-GJ@gemulon.postgresql.org Support parallel aggregation. ]<br />
* [https://www.postgresql.org/docs/9.6/static/functions-aggregate.html Supported built-in aggregate functions. ]<br />
* [https://www.depesz.com/2016/03/23/waiting-for-9-6-support-parallel-aggregation/ Waiting for 9.6 – Support parallel aggregation.]<br />
<br />
== postgres_fdw ==<br />
<br />
=== Sort pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aBS4o-0002l1-Tv@gemulon.postgresql.org postgres_fdw: postgres_fdw: Consider requesting sorted data so we can do a merge join. ]<br />
<br />
=== join pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aTDlV-0007xw-Vj@gemulon.postgresql.org postgres_fdw: Push down joins to remote servers. ]<br />
<br />
=== DML (UPDATE/DELETE) pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1agzA4-00074P-QW@gemulon.postgresql.org Directly modify foreign tables. ]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-directly-modify-foreign-tables/ Waiting for 9.6 – Directly modify foreign tables.]<br />
<br />
=== Operator and function pushdown ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pushdown-improvements-postgres-fdw/ Operator and function pushdown with postgres_fdw]<br />
<br />
== Replication ==<br />
<br />
=== New remote_apply replication mode which waits for confirmation that a standby has applied changes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1al4z1-0004qD-GW@gemulon.postgresql.org Add new replication mode synchronous_commit = 'remote_apply'. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-remote-apply/ Postgres 9.6 highlight - remote_apply]<br />
<br />
=== Support for multiple synchronous standbys ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aniiT-00083J-4W@gemulon.postgresql.org Support multiple synchronous standby servers. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-multi-sync-rep/ Postgres 9.6 highlight - multi-sync standbys]<br />
<br />
=== pg_stat_wal_receiver ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wal-receiver-status/ WAL receiver status view]<br />
<br />
=== Replication slots can allocate WAL at creation ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-replication-slot-improvements/ Postgres 9.6 feature highlight - Replication slot improvements]<br />
<br />
== Text Search ==<br />
<br />
=== Phrase full text search ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aoCJy-0004bp-HI@gemulon.postgresql.org Phrase full text search. ]<br />
* [https://lwn.net/Articles/689387/ pgCon and PostgreSQL 9.6]<br />
<br />
=== Editable tsvector fields ===<br />
<br />
Tsvector fields can now be modified in detail to fine-tune searchability.<br />
<br />
Links:<br />
<br />
* https://www.depesz.com/2016/03/21/waiting-for-9-6-tsvector-editing-functions/<br />
<br />
== Transactions, VACUUM and the Visibility Map ==<br />
<br />
=== pg_visibility extension for examining visibility maps ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adHwi-0007KB-TM@gemulon.postgresql.org Add pg_visibility contrib module. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-visibility/ Postgres 9.6 highlight - pg_visibility]<br />
<br />
=== Frozen page data in visibility map for skipping vacuum on already-frozen data ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae7wj-0001mM-Ib@gemulon.postgresql.org Don't vacuum all-frozen pages. ]<br />
<br />
=== User-defined expiration of snapshots to control table bloat ===<br />
<br />
Until now a long-running report or cursor displaying query results could block cleanup of dead rows, bloating all volatile tables in the database. The only options were to allow the bloat, suspend normal updates to other tables, or kill the long-running activity -- which might be completely unrelated to the bloating tables. Accumulation of bloat could cause performance problems and excessive use of storage space.<br />
<br />
A new configuration option called old_snapshot_threshold allows the cluster to be configured to allow cleanup of a dead row when the transaction which updated or deleted it (causing it to be dead) has completed and all snapshots which can still see it have reached a certain age, without immediately terminating activities which are using such snapshots. If, for example, a large monthly report is running off of data in table etl_monthly (which is not currently changing), bloat in other tables will be limited, and the report can run to completion without error. If a snapshot has passed the threshold and a query uses that snapshot to attempt to read data from a page modified recently enough that it might not produce accurate results, then a "snapshot too old" error will be thrown. Normally the goal in configuring old_snapshot_threshold is to set it high enough that such an error is rarely seen, while preventing problems caused by bloat.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aocLh-0006C7-2W@gemulon.postgresql.org Add the "snapshot too old" feature ]<br />
<br />
== psql ==<br />
<br />
=== \ev and \sv commands to edit views ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/07/21/waiting-for-9-6-add-psql-ev-and-sv-commands-for-editing-and-showing-view-definitions/ Waiting for 9.6 – Add psql \ev and \sv commands for editing and showing view definitions.]<br />
<br />
=== Prompt variable to show PId of backend ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/17/waiting-for-9-6-add-psql-prompt-variable-showing-the-pid-of-the-connected-to-backend/ Waiting for 9.6 – Add psql PROMPT variable showing the pid of the connected to backend.]<br />
<br />
=== Multiple -c and -f options ===<br />
<br />
* [https://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ support for multiple -c and -f options]<br />
<br />
=== Crosstabs in psql ===<br />
<br />
\crosstabview is a completely different way to display results from a<br />
query: instead of a vertical display of rows, the data values are placed<br />
in a grid where the column and row headers come from the data itself,<br />
similar to a spreadsheet.<br />
<br />
* [https://www.depesz.com/2016/04/27/waiting-for-9-6-support-crosstabview-in-psql/ Waiting for 9.6: Crosstabs in psql]<br />
<br />
== SQL commands ==<br />
<br />
=== ALTER TABLE ADD COLUMN IF NOT EXISTS ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/19/waiting-for-9-6-add-if-not-exists-processing-to-alter-table-add-column/ Waiting for 9.6 – Add IF NOT EXISTS processing to ALTER TABLE ADD COLUMN]<br />
<br />
=== ALTER TABLE SET and its locks ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-lower-locks-alter-table-set/ Lock reductions for ALTER TABLE SET]<br />
<br />
=== COPY and DML statements (CTEs) ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-copy-dml-statements/ COPY and DML statements]<br />
<br />
<br />
== Performance and Monitoring ==<br />
<br />
=== Detailed wait information in pg_stat_activity ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae5kR-0007wV-LY@gemulon.postgresql.org Provide much better wait information in pg_stat_activity. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wait-events/ Postgres 9.6 highlight - Tracking of wait events]<br />
<br />
=== Index-only scans for partial indexes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1alhet-0001o8-Hg@gemulon.postgresql.org Support using index-only scans with partial indexes in more case ]<br />
<br />
=== Performance improvements for external sort operations ===<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1aoQ56-0001hD-SR@gemulon.postgresql.org Use quicksort, not replacement selection, for external sorting ]<br />
<br />
* [http://www.postgresql.org/message-id/E1ageG4-0001Sj-RW@gemulon.postgresql.org Improve memory management for external sorts ]<br />
<br />
== System Views and Administration ==<br />
<br />
=== New system view pg_config ===<br />
<br />
* [https://www.depesz.com/2016/02/29/waiting-for-9-6-add-new-system-view-pg_config/ Waiting for 9.6 – Add new system view, pg_config]<br />
<br />
<br />
=== pg_blocking_pids ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-blocking-pids/ Postgres 9.6 highlight - pg_blocking_pids]<br />
<br />
=== Functions pg_get_* to return NULL on invalid objects ===<br />
<br />
Up to 9.6, such functions could have easily bumped on "cache lookup" errors.<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-behavior-change-pg-get/ Upcoming changes for pg_get functions on invalid objects]<br />
<br />
=== pg_notification_queue_usage to look at notify queue ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/18/waiting-for-9-6-add-new-function-pg_notification_queue_usage/ Waiting for 9.6 – Add new function pg_notification_queue_usage.]<br />
<br />
<br />
<br />
== Backups ==<br />
<br />
<br />
=== pg_basebackup extended with replication slots ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-base-backup-slot/ Postgres 9.6 feature highlight - pg_basebackup and replication slots]<br />
<br />
<br />
=== New API for hot physical backups ===<br />
<br />
Prior to PostgreSQL 9.6, the only way to perform concurrent physical backups was through pg_basebackup, via the streaming replication protocol. Low-level file system copy was only available in an exclusive mode, by calling pg_start_backup(), initiating the copy of data files, then finally calling pg_stop_backup().<br />
<br />
The limitation of taking one backup at a time has been overcome by a new native API which redefines the pg_start_backup() method and adds a variant to pg_stop_backup(). For back-compatibility, the older signatures have been kept.<br />
<br />
The new pg_start_backup function now accepts a third optional parameter, called 'exclusive', which is set by default to 'true' for backward compatibility.<br />
Initiating a concurrent (or if you prefer, a non-exclusive) backup is rather simple:<br />
<br />
SELECT pg_start_backup('my_label', false, false);<br />
<br />
If you are not familiar with pg_start_backup(), the first argument is a label for the backup, while the second is a request for a fast checkpoint operation. The third parameter, when set to false, requests a concurrent backup:<br />
<br />
postgres=# SELECT pg_start_backup('my_label', true, false);<br />
-[ RECORD 1 ]---+----------<br />
pg_start_backup | 0/F000028<br />
<br />
The PostgreSQL connection requesting the concurrent backup needs to remain active for the whole duration of the physical copy of data files (performed with your favourite tools such as rsync, cp, tar, SAN or LVM snapshots, ...). '''Note:''' this operation follows the same procedure as with prior versions of PostgreSQL (for detailed information, please refer to the documentation about continuous archiving and Point-In-Time-Recovery).<br />
<br />
When finished, we need to use the new version of pg_stop_backup() to specify that we are closing the current non-exclusive backup:<br />
<br />
SELECT * FROM pg_stop_backup(false);<br />
<br />
The different signature has a mandatory parameter, called 'exclusive', which<br />
needs to be set to 'false' for concurrent backup. The reason is that the function returns a different result, a row made up of three fields:<br />
<br />
# LSN, for backup consistency, returned at pg_stop_backup() time: identical to the previous version<br />
# the content of the label file: this needs to be saved as 'backup_label' in the main backup directory (new in 9.6)<br />
# the list of tablespaces: if not empty, this needs to be saved as 'tablespace_map' in the main backup directory (new in 9.6)<br />
<br />
For example:<br />
<br />
postgres=# SELECT * FROM pg_stop_backup(false);<br />
NOTICE: pg_stop_backup complete, all required WAL segments have been archived<br />
-[ RECORD 1 ]-------------------------------------------------------------<br />
lsn | 0/F000130<br />
labelfile | START WAL LOCATION: 0/F000028 (file 00000001000000000000000F)+<br />
| CHECKPOINT LOCATION: 0/F000060 +<br />
| BACKUP METHOD: streamed +<br />
| BACKUP FROM: master +<br />
| START TIME: 2016-05-16 09:19:44 CEST +<br />
| LABEL: my_label +<br />
| <br />
spcmapfile | 16386 /Users/gabriele/pg96/tbs1 +<br />
| 16388 /Users/gabriele/pg96/tbs2 +<br />
| <br />
<br />
As you can see, these two steps require users to change their customised backup scripts. However, users should expect common disaster recovery and backup external solutions such as [http://www.pgbarman.org/ Barman], [https://github.com/omniti-labs/omnipitr OmniPITR], [http://www.pgbackrest.org/ PgBackRest], [https://github.com/ohmu/pghoard pghoard], [https://github.com/wal-e/wal-e WAL-E] to transparently manage this new behaviour introduced in 9.6.<br />
<br />
This new in-core API replaces the pgespresso package that was previously used with Barman 1.3.1 and above. Barman 2.0 now supports both pgespresso for PG9.2-PG9.5 and the new 9.6 API.<br />
<br />
'''IMPORTANT:''' this new API will become the only supported way in the future to coordinate low level backup operations with PostgreSQL.<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1anVSA-0002zm-Gc@gemulon.postgresql.org Implement backup API functions for non-exclusive backups]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-non-exclusive-backup/ Postgres 9.6 highlight - Non-exclusive base backups]<br />
<br />
<br />
== Extensions and Contrib Modules ==<br />
<br />
=== Extension cascade support to install dependencies ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZiPzU-0004m0-Lq@gemulon.postgresql.org Add CASCADE support for CREATE EXTENSION. ]<br />
* [https://www.depesz.com/2015/10/08/waiting-for-9-6-add-cascade-support-for-create-extension/ Waiting for 9.6 – Add CASCADE support for CREATE EXTENSION]<br />
<br />
=== Cube extension kNN support ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1a9tQP-0004Qd-R7@gemulon.postgresql.org Cube extension kNN support ]<br />
<br />
<br />
== Other Features ==<br />
<br />
<br />
=== Command progress reporting ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adhjH-0008RE-TV@gemulon.postgresql.org Add a generic command progress reporting facility. ]<br />
* [http://www.postgresql.org/message-id/E1afsqY-0003qB-Mb@gemulon.postgresql.org Add simple VACUUM progress reporting. ]<br />
* [https://www.depesz.com/2016/03/09/waiting-for-9-6-add-a-generic-command-progress-reporting-facility/ Waiting for 9.6 – Add a generic command progress reporting facility.]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-add-simple-vacuum-progress-reporting/ Waiting for 9.6 – Add simple VACUUM progress reporting.]<br />
<br />
<br />
<br />
<br />
=== Generic WAL facility ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-generic-wal-interface/ Postgres 9.6 highlight - Generic WAL interface]<br />
<br />
<br />
<br />
=== Trigonometric functions in degrees ===<br />
<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-add-trigonometric-functions-that-work-in-degrees/ Waiting for 9.6 – Add trigonometric functions that work in degrees.]</div>Agliohttps://wiki.postgresql.org/index.php?title=NewIn96&diff=28270NewIn962016-09-28T18:46:38Z<p>Aglio: </p>
<hr />
<div>= What's New in PostgreSQL 9.6 =<br />
<br />
This page is a work in progress which will include details of PostgreSQL 9.6 features and changes. Many thanks to Thom Brown for assembling the original list.<br />
<br />
== Parallel Query ==<br />
<br />
=== Parallel sequential scans ===<br />
<br />
PostgreSQL can now execute a full table scan in multiple parallel processes, up to the limits set by the user.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZwVzN-0000Xz-5e@gemulon.postgresql.org Generate parallel sequential scan plans in simple cases. ]<br />
* [https://www.depesz.com/2015/11/17/waiting-for-9-6-generate-parallel-sequential-scan-plans-in-simple-cases/ Waiting for 9.6 – Generate parallel sequential scan plans in simple cases.]<br />
* [https://lwn.net/Articles/689387/ pgCon and PostgreSQL 9.6]<br />
<br />
=== parallel joins ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aLyct-000314-UZ@gemulon.postgresql.org Support parallel joins, and make related improvements. ]<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-support-parallel-joins-and-make-related-improvements/ Waiting for 9.6 – Support parallel joins, and make related improvements.]<br />
<br />
=== parallel aggregates ===<br />
<br />
Parallel Aggregates allow aggregate functions to be processed concurrently by multiple worker processes. This can significantly increase the response times for queries aggregating large amounts of tuples down to just a few aggregate groups, providing that the server has enough otherwise idle CPUs and would otherwise be bounded by the single CPU which the backend process is running on. Each worker process operates on a subset of tuples and creates a partially aggregated result to which it returns to the main backend process where each partial result will be combined with ones from the other worker processes and the final aggregate result produced.<br />
<br />
Most internal aggregate functions support parallel mode. User defined aggregates will need to be changed to add a combine function, and possible a serialization and deserialization in the case of aggregate functions which return an INTERNAL state.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ahzxY-0004qA-GJ@gemulon.postgresql.org Support parallel aggregation. ]<br />
* [https://www.postgresql.org/docs/9.6/static/functions-aggregate.html Supported built-in aggregate functions. ]<br />
* [https://www.depesz.com/2016/03/23/waiting-for-9-6-support-parallel-aggregation/ Waiting for 9.6 – Support parallel aggregation.]<br />
<br />
== postgres_fdw ==<br />
<br />
=== Sort pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aBS4o-0002l1-Tv@gemulon.postgresql.org postgres_fdw: postgres_fdw: Consider requesting sorted data so we can do a merge join. ]<br />
<br />
=== join pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aTDlV-0007xw-Vj@gemulon.postgresql.org postgres_fdw: Push down joins to remote servers. ]<br />
<br />
=== DML (UPDATE/DELETE) pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1agzA4-00074P-QW@gemulon.postgresql.org Directly modify foreign tables. ]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-directly-modify-foreign-tables/ Waiting for 9.6 – Directly modify foreign tables.]<br />
<br />
=== Operator and function pushdown ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pushdown-improvements-postgres-fdw/ Operator and function pushdown with postgres_fdw]<br />
<br />
== Replication ==<br />
<br />
=== New remote_apply replication mode which waits for confirmation that a standby has applied changes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1al4z1-0004qD-GW@gemulon.postgresql.org Add new replication mode synchronous_commit = 'remote_apply'. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-remote-apply/ Postgres 9.6 highlight - remote_apply]<br />
<br />
=== Support for multiple synchronous standbys ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aniiT-00083J-4W@gemulon.postgresql.org Support multiple synchronous standby servers. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-multi-sync-rep/ Postgres 9.6 highlight - multi-sync standbys]<br />
<br />
=== pg_stat_wal_receiver ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wal-receiver-status/ WAL receiver status view]<br />
<br />
=== Replication slots can allocate WAL at creation ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-replication-slot-improvements/ Postgres 9.6 feature highlight - Replication slot improvements]<br />
<br />
== Text Search ==<br />
<br />
=== Phrase full text search ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aoCJy-0004bp-HI@gemulon.postgresql.org Phrase full text search. ]<br />
* [https://lwn.net/Articles/689387/ pgCon and PostgreSQL 9.6]<br />
<br />
=== Editable tsvector fields ===<br />
<br />
Tsvector fields can now be modified in detail to fine-tune searchability.<br />
<br />
Links:<br />
<br />
* https://www.depesz.com/2016/03/21/waiting-for-9-6-tsvector-editing-functions/<br />
<br />
== Transactions, VACUUM and the Visibility Map ==<br />
<br />
=== pg_visibility extension for examining visibility maps ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adHwi-0007KB-TM@gemulon.postgresql.org Add pg_visibility contrib module. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-visibility/ Postgres 9.6 highlight - pg_visibility]<br />
<br />
=== Frozen page data in visibility map for skipping vacuum on already-frozen data ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae7wj-0001mM-Ib@gemulon.postgresql.org Don't vacuum all-frozen pages. ]<br />
<br />
=== User-defined expiration of snapshots to control table bloat ===<br />
<br />
Until now a long-running report or cursor displaying query results could block cleanup of dead rows, bloating all volatile tables in the database. The only options were to allow the bloat, suspend normal updates to other tables, or kill the long-running activity -- which might be completely unrelated to the bloating tables. Accumulation of bloat could cause performance problems and excessive use of storage space.<br />
<br />
A new configuration option called old_snapshot_threshold allows the cluster to be configured to allow cleanup of a dead row when the transaction which updated or deleted it (causing it to be dead) has completed and all snapshots which can still see it have reached a certain age, without immediately terminating activities which are using such snapshots. If, for example, a large monthly report is running off of data in table etl_monthly (which is not currently changing), bloat in other tables will be limited, and the report can run to completion without error. If a snapshot has passed the threshold and a query uses that snapshot to attempt to read data from a page modified recently enough that it might not produce accurate results, then a "snapshot too old" error will be thrown. Normally the goal in configuring old_snapshot_threshold is to set it high enough that such an error is rarely seen, while preventing problems caused by bloat.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aocLh-0006C7-2W@gemulon.postgresql.org Add the "snapshot too old" feature ]<br />
<br />
== psql ==<br />
<br />
=== \ev and \sv commands to edit views ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/07/21/waiting-for-9-6-add-psql-ev-and-sv-commands-for-editing-and-showing-view-definitions/ Waiting for 9.6 – Add psql \ev and \sv commands for editing and showing view definitions.]<br />
<br />
=== Prompt variable to show PId of backend ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/17/waiting-for-9-6-add-psql-prompt-variable-showing-the-pid-of-the-connected-to-backend/ Waiting for 9.6 – Add psql PROMPT variable showing the pid of the connected to backend.]<br />
<br />
=== Multiple -c and -f options ===<br />
<br />
* [https://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ support for multiple -c and -f options]<br />
<br />
=== Crosstabs in psql ===<br />
<br />
\crosstabview is a completely different way to display results from a<br />
query: instead of a vertical display of rows, the data values are placed<br />
in a grid where the column and row headers come from the data itself,<br />
similar to a spreadsheet.<br />
<br />
* [https://www.depesz.com/2016/04/27/waiting-for-9-6-support-crosstabview-in-psql/ Waiting for 9.6: Crosstabs in psql]<br />
<br />
== SQL commands ==<br />
<br />
=== ALTER TABLE ADD COLUMN IF NOT EXISTS ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/19/waiting-for-9-6-add-if-not-exists-processing-to-alter-table-add-column/ Waiting for 9.6 – Add IF NOT EXISTS processing to ALTER TABLE ADD COLUMN]<br />
<br />
=== ALTER TABLE SET and its locks ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-lower-locks-alter-table-set/ Lock reductions for ALTER TABLE SET]<br />
<br />
=== COPY and DML statements (CTEs) ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-copy-dml-statements/ COPY and DML statements]<br />
<br />
<br />
== Performance and Monitoring ==<br />
<br />
=== Detailed wait information in pg_stat_activity ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae5kR-0007wV-LY@gemulon.postgresql.org Provide much better wait information in pg_stat_activity. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wait-events/ Postgres 9.6 highlight - Tracking of wait events]<br />
<br />
=== Index-only scans for partial indexes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1alhet-0001o8-Hg@gemulon.postgresql.org Support using index-only scans with partial indexes in more case ]<br />
<br />
=== Performance improvements for external sort operations ===<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1aoQ56-0001hD-SR@gemulon.postgresql.org Use quicksort, not replacement selection, for external sorting ]<br />
<br />
* [http://www.postgresql.org/message-id/E1ageG4-0001Sj-RW@gemulon.postgresql.org Improve memory management for external sorts ]<br />
<br />
== System Views and Administration ==<br />
<br />
<br />
== Backups ==<br />
<br />
<br />
=== pg_basebackup extended with replication slots ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-base-backup-slot/ Postgres 9.6 feature highlight - pg_basebackup and replication slots]<br />
<br />
<br />
=== New API for hot physical backups ===<br />
<br />
Prior to PostgreSQL 9.6, the only way to perform concurrent physical backups was through pg_basebackup, via the streaming replication protocol. Low-level file system copy was only available in an exclusive mode, by calling pg_start_backup(), initiating the copy of data files, then finally calling pg_stop_backup().<br />
<br />
The limitation of taking one backup at a time has been overcome by a new native API which redefines the pg_start_backup() method and adds a variant to pg_stop_backup(). For back-compatibility, the older signatures have been kept.<br />
<br />
The new pg_start_backup function now accepts a third optional parameter, called 'exclusive', which is set by default to 'true' for backward compatibility.<br />
Initiating a concurrent (or if you prefer, a non-exclusive) backup is rather simple:<br />
<br />
SELECT pg_start_backup('my_label', false, false);<br />
<br />
If you are not familiar with pg_start_backup(), the first argument is a label for the backup, while the second is a request for a fast checkpoint operation. The third parameter, when set to false, requests a concurrent backup:<br />
<br />
postgres=# SELECT pg_start_backup('my_label', true, false);<br />
-[ RECORD 1 ]---+----------<br />
pg_start_backup | 0/F000028<br />
<br />
The PostgreSQL connection requesting the concurrent backup needs to remain active for the whole duration of the physical copy of data files (performed with your favourite tools such as rsync, cp, tar, SAN or LVM snapshots, ...). '''Note:''' this operation follows the same procedure as with prior versions of PostgreSQL (for detailed information, please refer to the documentation about continuous archiving and Point-In-Time-Recovery).<br />
<br />
When finished, we need to use the new version of pg_stop_backup() to specify that we are closing the current non-exclusive backup:<br />
<br />
SELECT * FROM pg_stop_backup(false);<br />
<br />
The different signature has a mandatory parameter, called 'exclusive', which<br />
needs to be set to 'false' for concurrent backup. The reason is that the function returns a different result, a row made up of three fields:<br />
<br />
# LSN, for backup consistency, returned at pg_stop_backup() time: identical to the previous version<br />
# the content of the label file: this needs to be saved as 'backup_label' in the main backup directory (new in 9.6)<br />
# the list of tablespaces: if not empty, this needs to be saved as 'tablespace_map' in the main backup directory (new in 9.6)<br />
<br />
For example:<br />
<br />
postgres=# SELECT * FROM pg_stop_backup(false);<br />
NOTICE: pg_stop_backup complete, all required WAL segments have been archived<br />
-[ RECORD 1 ]-------------------------------------------------------------<br />
lsn | 0/F000130<br />
labelfile | START WAL LOCATION: 0/F000028 (file 00000001000000000000000F)+<br />
| CHECKPOINT LOCATION: 0/F000060 +<br />
| BACKUP METHOD: streamed +<br />
| BACKUP FROM: master +<br />
| START TIME: 2016-05-16 09:19:44 CEST +<br />
| LABEL: my_label +<br />
| <br />
spcmapfile | 16386 /Users/gabriele/pg96/tbs1 +<br />
| 16388 /Users/gabriele/pg96/tbs2 +<br />
| <br />
<br />
As you can see, these two steps require users to change their customised backup scripts. However, users should expect common disaster recovery and backup external solutions such as [http://www.pgbarman.org/ Barman], [https://github.com/omniti-labs/omnipitr OmniPITR], [http://www.pgbackrest.org/ PgBackRest], [https://github.com/ohmu/pghoard pghoard], [https://github.com/wal-e/wal-e WAL-E] to transparently manage this new behaviour introduced in 9.6.<br />
<br />
This new in-core API replaces the pgespresso package that was previously used with Barman 1.3.1 and above. Barman 2.0 now supports both pgespresso for PG9.2-PG9.5 and the new 9.6 API.<br />
<br />
'''IMPORTANT:''' this new API will become the only supported way in the future to coordinate low level backup operations with PostgreSQL.<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1anVSA-0002zm-Gc@gemulon.postgresql.org Implement backup API functions for non-exclusive backups]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-non-exclusive-backup/ Postgres 9.6 highlight - Non-exclusive base backups]<br />
<br />
<br />
== Extensions and Contrib Modules ==<br />
<br />
=== Extension cascade support to install dependencies ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZiPzU-0004m0-Lq@gemulon.postgresql.org Add CASCADE support for CREATE EXTENSION. ]<br />
<br />
=== Cube extension kNN support ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1a9tQP-0004Qd-R7@gemulon.postgresql.org Cube extension kNN support ]<br />
<br />
<br />
== Other Features ==<br />
<br />
<br />
=== Command progress reporting ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adhjH-0008RE-TV@gemulon.postgresql.org Add a generic command progress reporting facility. ]<br />
* [http://www.postgresql.org/message-id/E1afsqY-0003qB-Mb@gemulon.postgresql.org Add simple VACUUM progress reporting. ]<br />
* [https://www.depesz.com/2016/03/09/waiting-for-9-6-add-a-generic-command-progress-reporting-facility/ Waiting for 9.6 – Add a generic command progress reporting facility.]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-add-simple-vacuum-progress-reporting/ Waiting for 9.6 – Add simple VACUUM progress reporting.]<br />
<br />
<br />
<br />
<br />
=== Generic WAL facility ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-generic-wal-interface/ Postgres 9.6 highlight - Generic WAL interface]<br />
<br />
=== pg_blocking_pids ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-blocking-pids/ Postgres 9.6 highlight - pg_blocking_pids]<br />
<br />
=== Functions pg_get_* to return NULL on invalid objects ===<br />
<br />
Up to 9.6, such functions could have easily bumped on "cache lookup" errors.<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-behavior-change-pg-get/ Upcoming changes for pg_get functions on invalid objects]<br />
<br />
=== pg_notification_queue_usage to look at notify queue ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/18/waiting-for-9-6-add-new-function-pg_notification_queue_usage/ Waiting for 9.6 – Add new function pg_notification_queue_usage.]<br />
<br />
=== Extensions: CASCADE support ===<br />
<br />
* [https://www.depesz.com/2015/10/08/waiting-for-9-6-add-cascade-support-for-create-extension/ Waiting for 9.6 – Add CASCADE support for CREATE EXTENSION]<br />
<br />
=== Trigonometric functions in degrees ===<br />
<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-add-trigonometric-functions-that-work-in-degrees/ Waiting for 9.6 – Add trigonometric functions that work in degrees.]<br />
<br />
=== New system view pg_config ===<br />
<br />
* [https://www.depesz.com/2016/02/29/waiting-for-9-6-add-new-system-view-pg_config/ Waiting for 9.6 – Add new system view, pg_config]</div>Agliohttps://wiki.postgresql.org/index.php?title=NewIn96&diff=28269NewIn962016-09-28T18:39:26Z<p>Aglio: </p>
<hr />
<div>= What's New in PostgreSQL 9.6 =<br />
<br />
This page is a work in progress which will include details of PostgreSQL 9.6 features and changes. Many thanks to Thom Brown for assembling the original list.<br />
<br />
== Parallel Query ==<br />
<br />
=== Parallel sequential scans ===<br />
<br />
PostgreSQL can now execute a full table scan in multiple parallel processes, up to the limits set by the user.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZwVzN-0000Xz-5e@gemulon.postgresql.org Generate parallel sequential scan plans in simple cases. ]<br />
* [https://www.depesz.com/2015/11/17/waiting-for-9-6-generate-parallel-sequential-scan-plans-in-simple-cases/ Waiting for 9.6 – Generate parallel sequential scan plans in simple cases.]<br />
* [https://lwn.net/Articles/689387/ pgCon and PostgreSQL 9.6]<br />
<br />
=== parallel joins ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aLyct-000314-UZ@gemulon.postgresql.org Support parallel joins, and make related improvements. ]<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-support-parallel-joins-and-make-related-improvements/ Waiting for 9.6 – Support parallel joins, and make related improvements.]<br />
<br />
=== parallel aggregates ===<br />
<br />
Parallel Aggregates allow aggregate functions to be processed concurrently by multiple worker processes. This can significantly increase the response times for queries aggregating large amounts of tuples down to just a few aggregate groups, providing that the server has enough otherwise idle CPUs and would otherwise be bounded by the single CPU which the backend process is running on. Each worker process operates on a subset of tuples and creates a partially aggregated result to which it returns to the main backend process where each partial result will be combined with ones from the other worker processes and the final aggregate result produced.<br />
<br />
Most internal aggregate functions support parallel mode. User defined aggregates will need to be changed to add a combine function, and possible a serialization and deserialization in the case of aggregate functions which return an INTERNAL state.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ahzxY-0004qA-GJ@gemulon.postgresql.org Support parallel aggregation. ]<br />
* [https://www.postgresql.org/docs/9.6/static/functions-aggregate.html Supported built-in aggregate functions. ]<br />
* [https://www.depesz.com/2016/03/23/waiting-for-9-6-support-parallel-aggregation/ Waiting for 9.6 – Support parallel aggregation.]<br />
<br />
== postgres_fdw ==<br />
<br />
=== Sort pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aBS4o-0002l1-Tv@gemulon.postgresql.org postgres_fdw: postgres_fdw: Consider requesting sorted data so we can do a merge join. ]<br />
<br />
=== join pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aTDlV-0007xw-Vj@gemulon.postgresql.org postgres_fdw: Push down joins to remote servers. ]<br />
<br />
=== DML (UPDATE/DELETE) pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1agzA4-00074P-QW@gemulon.postgresql.org Directly modify foreign tables. ]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-directly-modify-foreign-tables/ Waiting for 9.6 – Directly modify foreign tables.]<br />
<br />
=== Operator and function pushdown ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pushdown-improvements-postgres-fdw/ Operator and function pushdown with postgres_fdw]<br />
<br />
== Replication ==<br />
<br />
=== New remote_apply replication mode which waits for confirmation that a standby has applied changes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1al4z1-0004qD-GW@gemulon.postgresql.org Add new replication mode synchronous_commit = 'remote_apply'. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-remote-apply/ Postgres 9.6 highlight - remote_apply]<br />
<br />
=== Support for multiple synchronous standbys ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aniiT-00083J-4W@gemulon.postgresql.org Support multiple synchronous standby servers. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-multi-sync-rep/ Postgres 9.6 highlight - multi-sync standbys]<br />
<br />
=== pg_stat_wal_receiver ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wal-receiver-status/ WAL receiver status view]<br />
<br />
== Text Search ==<br />
<br />
=== Phrase full text search ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aoCJy-0004bp-HI@gemulon.postgresql.org Phrase full text search. ]<br />
* [https://lwn.net/Articles/689387/ pgCon and PostgreSQL 9.6]<br />
<br />
=== Editable tsvector fields ===<br />
<br />
Tsvector fields can now be modified in detail to fine-tune searchability.<br />
<br />
Links:<br />
<br />
* https://www.depesz.com/2016/03/21/waiting-for-9-6-tsvector-editing-functions/<br />
<br />
== Transactions, VACUUM and the Visibility Map ==<br />
<br />
=== pg_visibility extension for examining visibility maps ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adHwi-0007KB-TM@gemulon.postgresql.org Add pg_visibility contrib module. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-visibility/ Postgres 9.6 highlight - pg_visibility]<br />
<br />
=== Frozen page data in visibility map for skipping vacuum on already-frozen data ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae7wj-0001mM-Ib@gemulon.postgresql.org Don't vacuum all-frozen pages. ]<br />
<br />
=== User-defined expiration of snapshots to control table bloat ===<br />
<br />
Until now a long-running report or cursor displaying query results could block cleanup of dead rows, bloating all volatile tables in the database. The only options were to allow the bloat, suspend normal updates to other tables, or kill the long-running activity -- which might be completely unrelated to the bloating tables. Accumulation of bloat could cause performance problems and excessive use of storage space.<br />
<br />
A new configuration option called old_snapshot_threshold allows the cluster to be configured to allow cleanup of a dead row when the transaction which updated or deleted it (causing it to be dead) has completed and all snapshots which can still see it have reached a certain age, without immediately terminating activities which are using such snapshots. If, for example, a large monthly report is running off of data in table etl_monthly (which is not currently changing), bloat in other tables will be limited, and the report can run to completion without error. If a snapshot has passed the threshold and a query uses that snapshot to attempt to read data from a page modified recently enough that it might not produce accurate results, then a "snapshot too old" error will be thrown. Normally the goal in configuring old_snapshot_threshold is to set it high enough that such an error is rarely seen, while preventing problems caused by bloat.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aocLh-0006C7-2W@gemulon.postgresql.org Add the "snapshot too old" feature ]<br />
<br />
== psql ==<br />
<br />
=== \ev and \sv commands to edit views ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/07/21/waiting-for-9-6-add-psql-ev-and-sv-commands-for-editing-and-showing-view-definitions/ Waiting for 9.6 – Add psql \ev and \sv commands for editing and showing view definitions.]<br />
<br />
=== Prompt variable to show PId of backend ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/17/waiting-for-9-6-add-psql-prompt-variable-showing-the-pid-of-the-connected-to-backend/ Waiting for 9.6 – Add psql PROMPT variable showing the pid of the connected to backend.]<br />
<br />
=== Multiple -c and -f options ===<br />
<br />
* [https://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ support for multiple -c and -f options]<br />
<br />
=== Crosstabs in psql ===<br />
<br />
\crosstabview is a completely different way to display results from a<br />
query: instead of a vertical display of rows, the data values are placed<br />
in a grid where the column and row headers come from the data itself,<br />
similar to a spreadsheet.<br />
<br />
* [https://www.depesz.com/2016/04/27/waiting-for-9-6-support-crosstabview-in-psql/ Waiting for 9.6: Crosstabs in psql]<br />
<br />
== SQL commands ==<br />
<br />
=== ALTER TABLE ADD COLUMN IF NOT EXISTS ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/19/waiting-for-9-6-add-if-not-exists-processing-to-alter-table-add-column/ Waiting for 9.6 – Add IF NOT EXISTS processing to ALTER TABLE ADD COLUMN]<br />
<br />
=== ALTER TABLE SET and its locks ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-lower-locks-alter-table-set/ Lock reductions for ALTER TABLE SET]<br />
<br />
== Other Features ==<br />
<br />
=== Extension cascade support to install dependencies ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZiPzU-0004m0-Lq@gemulon.postgresql.org Add CASCADE support for CREATE EXTENSION. ]<br />
<br />
=== Cube extension kNN support ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1a9tQP-0004Qd-R7@gemulon.postgresql.org Cube extension kNN support ]<br />
<br />
<br />
=== Command progress reporting ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adhjH-0008RE-TV@gemulon.postgresql.org Add a generic command progress reporting facility. ]<br />
* [http://www.postgresql.org/message-id/E1afsqY-0003qB-Mb@gemulon.postgresql.org Add simple VACUUM progress reporting. ]<br />
* [https://www.depesz.com/2016/03/09/waiting-for-9-6-add-a-generic-command-progress-reporting-facility/ Waiting for 9.6 – Add a generic command progress reporting facility.]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-add-simple-vacuum-progress-reporting/ Waiting for 9.6 – Add simple VACUUM progress reporting.]<br />
<br />
=== Detailed wait information in pg_stat_activity ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae5kR-0007wV-LY@gemulon.postgresql.org Provide much better wait information in pg_stat_activity. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wait-events/ Postgres 9.6 highlight - Tracking of wait events]<br />
<br />
=== Index-only scans for partial indexes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1alhet-0001o8-Hg@gemulon.postgresql.org Support using index-only scans with partial indexes in more case ]<br />
<br />
=== Performance improvements for external sort operations ===<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1aoQ56-0001hD-SR@gemulon.postgresql.org Use quicksort, not replacement selection, for external sorting ]<br />
<br />
* [http://www.postgresql.org/message-id/E1ageG4-0001Sj-RW@gemulon.postgresql.org Improve memory management for external sorts ]<br />
<br />
<br />
=== pg_basebackup extended with replication slots ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-base-backup-slot/ Postgres 9.6 feature highlight - pg_basebackup and replication slots]<br />
<br />
=== Replication slots can allocate WAL at creation ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-replication-slot-improvements/ Postgres 9.6 feature highlight - Replication slot improvements]<br />
<br />
=== New API for hot physical backups ===<br />
<br />
Prior to PostgreSQL 9.6, the only way to perform concurrent physical backups was through pg_basebackup, via the streaming replication protocol. Low-level file system copy was only available in an exclusive mode, by calling pg_start_backup(), initiating the copy of data files, then finally calling pg_stop_backup().<br />
<br />
The limitation of taking one backup at a time has been overcome by a new native API which redefines the pg_start_backup() method and adds a variant to pg_stop_backup(). For back-compatibility, the older signatures have been kept.<br />
<br />
The new pg_start_backup function now accepts a third optional parameter, called 'exclusive', which is set by default to 'true' for backward compatibility.<br />
Initiating a concurrent (or if you prefer, a non-exclusive) backup is rather simple:<br />
<br />
SELECT pg_start_backup('my_label', false, false);<br />
<br />
If you are not familiar with pg_start_backup(), the first argument is a label for the backup, while the second is a request for a fast checkpoint operation. The third parameter, when set to false, requests a concurrent backup:<br />
<br />
postgres=# SELECT pg_start_backup('my_label', true, false);<br />
-[ RECORD 1 ]---+----------<br />
pg_start_backup | 0/F000028<br />
<br />
The PostgreSQL connection requesting the concurrent backup needs to remain active for the whole duration of the physical copy of data files (performed with your favourite tools such as rsync, cp, tar, SAN or LVM snapshots, ...). '''Note:''' this operation follows the same procedure as with prior versions of PostgreSQL (for detailed information, please refer to the documentation about continuous archiving and Point-In-Time-Recovery).<br />
<br />
When finished, we need to use the new version of pg_stop_backup() to specify that we are closing the current non-exclusive backup:<br />
<br />
SELECT * FROM pg_stop_backup(false);<br />
<br />
The different signature has a mandatory parameter, called 'exclusive', which<br />
needs to be set to 'false' for concurrent backup. The reason is that the function returns a different result, a row made up of three fields:<br />
<br />
# LSN, for backup consistency, returned at pg_stop_backup() time: identical to the previous version<br />
# the content of the label file: this needs to be saved as 'backup_label' in the main backup directory (new in 9.6)<br />
# the list of tablespaces: if not empty, this needs to be saved as 'tablespace_map' in the main backup directory (new in 9.6)<br />
<br />
For example:<br />
<br />
postgres=# SELECT * FROM pg_stop_backup(false);<br />
NOTICE: pg_stop_backup complete, all required WAL segments have been archived<br />
-[ RECORD 1 ]-------------------------------------------------------------<br />
lsn | 0/F000130<br />
labelfile | START WAL LOCATION: 0/F000028 (file 00000001000000000000000F)+<br />
| CHECKPOINT LOCATION: 0/F000060 +<br />
| BACKUP METHOD: streamed +<br />
| BACKUP FROM: master +<br />
| START TIME: 2016-05-16 09:19:44 CEST +<br />
| LABEL: my_label +<br />
| <br />
spcmapfile | 16386 /Users/gabriele/pg96/tbs1 +<br />
| 16388 /Users/gabriele/pg96/tbs2 +<br />
| <br />
<br />
As you can see, these two steps require users to change their customised backup scripts. However, users should expect common disaster recovery and backup external solutions such as [http://www.pgbarman.org/ Barman], [https://github.com/omniti-labs/omnipitr OmniPITR], [http://www.pgbackrest.org/ PgBackRest], [https://github.com/ohmu/pghoard pghoard], [https://github.com/wal-e/wal-e WAL-E] to transparently manage this new behaviour introduced in 9.6.<br />
<br />
This new in-core API replaces the pgespresso package that was previously used with Barman 1.3.1 and above. Barman 2.0 now supports both pgespresso for PG9.2-PG9.5 and the new 9.6 API.<br />
<br />
'''IMPORTANT:''' this new API will become the only supported way in the future to coordinate low level backup operations with PostgreSQL.<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1anVSA-0002zm-Gc@gemulon.postgresql.org Implement backup API functions for non-exclusive backups]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-non-exclusive-backup/ Postgres 9.6 highlight - Non-exclusive base backups]<br />
<br />
=== COPY and DML statements (CTEs) ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-copy-dml-statements/ COPY and DML statements]<br />
<br />
=== Generic WAL facility ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-generic-wal-interface/ Postgres 9.6 highlight - Generic WAL interface]<br />
<br />
=== pg_blocking_pids ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-blocking-pids/ Postgres 9.6 highlight - pg_blocking_pids]<br />
<br />
=== Functions pg_get_* to return NULL on invalid objects ===<br />
<br />
Up to 9.6, such functions could have easily bumped on "cache lookup" errors.<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-behavior-change-pg-get/ Upcoming changes for pg_get functions on invalid objects]<br />
<br />
=== pg_notification_queue_usage to look at notify queue ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/18/waiting-for-9-6-add-new-function-pg_notification_queue_usage/ Waiting for 9.6 – Add new function pg_notification_queue_usage.]<br />
<br />
=== Extensions: CASCADE support ===<br />
<br />
* [https://www.depesz.com/2015/10/08/waiting-for-9-6-add-cascade-support-for-create-extension/ Waiting for 9.6 – Add CASCADE support for CREATE EXTENSION]<br />
<br />
=== Trigonometric functions in degrees ===<br />
<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-add-trigonometric-functions-that-work-in-degrees/ Waiting for 9.6 – Add trigonometric functions that work in degrees.]<br />
<br />
=== New system view pg_config ===<br />
<br />
* [https://www.depesz.com/2016/02/29/waiting-for-9-6-add-new-system-view-pg_config/ Waiting for 9.6 – Add new system view, pg_config]</div>Agliohttps://wiki.postgresql.org/index.php?title=NewIn96&diff=28268NewIn962016-09-28T18:34:02Z<p>Aglio: /* Phrase full text search */</p>
<hr />
<div>= What's New in PostgreSQL 9.6 =<br />
<br />
This page is a work in progress which will include details of PostgreSQL 9.6 features and changes. Many thanks to Thom Brown for assembling the original list.<br />
<br />
== Parallel Query ==<br />
<br />
=== Parallel sequential scans ===<br />
<br />
PostgreSQL can now execute a full table scan in multiple parallel processes, up to the limits set by the user.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZwVzN-0000Xz-5e@gemulon.postgresql.org Generate parallel sequential scan plans in simple cases. ]<br />
* [https://www.depesz.com/2015/11/17/waiting-for-9-6-generate-parallel-sequential-scan-plans-in-simple-cases/ Waiting for 9.6 – Generate parallel sequential scan plans in simple cases.]<br />
* [https://lwn.net/Articles/689387/ pgCon and PostgreSQL 9.6]<br />
<br />
=== parallel joins ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aLyct-000314-UZ@gemulon.postgresql.org Support parallel joins, and make related improvements. ]<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-support-parallel-joins-and-make-related-improvements/ Waiting for 9.6 – Support parallel joins, and make related improvements.]<br />
<br />
=== parallel aggregates ===<br />
<br />
Parallel Aggregates allow aggregate functions to be processed concurrently by multiple worker processes. This can significantly increase the response times for queries aggregating large amounts of tuples down to just a few aggregate groups, providing that the server has enough otherwise idle CPUs and would otherwise be bounded by the single CPU which the backend process is running on. Each worker process operates on a subset of tuples and creates a partially aggregated result to which it returns to the main backend process where each partial result will be combined with ones from the other worker processes and the final aggregate result produced.<br />
<br />
Most internal aggregate functions support parallel mode. User defined aggregates will need to be changed to add a combine function, and possible a serialization and deserialization in the case of aggregate functions which return an INTERNAL state.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ahzxY-0004qA-GJ@gemulon.postgresql.org Support parallel aggregation. ]<br />
* [https://www.postgresql.org/docs/9.6/static/functions-aggregate.html Supported built-in aggregate functions. ]<br />
* [https://www.depesz.com/2016/03/23/waiting-for-9-6-support-parallel-aggregation/ Waiting for 9.6 – Support parallel aggregation.]<br />
<br />
== postgres_fdw ==<br />
<br />
=== Sort pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aBS4o-0002l1-Tv@gemulon.postgresql.org postgres_fdw: postgres_fdw: Consider requesting sorted data so we can do a merge join. ]<br />
<br />
=== join pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aTDlV-0007xw-Vj@gemulon.postgresql.org postgres_fdw: Push down joins to remote servers. ]<br />
<br />
=== DML (UPDATE/DELETE) pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1agzA4-00074P-QW@gemulon.postgresql.org Directly modify foreign tables. ]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-directly-modify-foreign-tables/ Waiting for 9.6 – Directly modify foreign tables.]<br />
<br />
=== Operator and function pushdown ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pushdown-improvements-postgres-fdw/ Operator and function pushdown with postgres_fdw]<br />
<br />
== Replication ==<br />
<br />
=== New remote_apply replication mode which waits for confirmation that a standby has applied changes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1al4z1-0004qD-GW@gemulon.postgresql.org Add new replication mode synchronous_commit = 'remote_apply'. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-remote-apply/ Postgres 9.6 highlight - remote_apply]<br />
<br />
=== Support for multiple synchronous standbys ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aniiT-00083J-4W@gemulon.postgresql.org Support multiple synchronous standby servers. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-multi-sync-rep/ Postgres 9.6 highlight - multi-sync standbys]<br />
<br />
=== pg_stat_wal_receiver ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wal-receiver-status/ WAL receiver status view]<br />
<br />
== Transactions, VACUUM and the Visibility Map ==<br />
<br />
=== pg_visibility extension for examining visibility maps ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adHwi-0007KB-TM@gemulon.postgresql.org Add pg_visibility contrib module. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-visibility/ Postgres 9.6 highlight - pg_visibility]<br />
<br />
=== Frozen page data in visibility map for skipping vacuum on already-frozen data ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae7wj-0001mM-Ib@gemulon.postgresql.org Don't vacuum all-frozen pages. ]<br />
<br />
=== User-defined expiration of snapshots to control table bloat ===<br />
<br />
Until now a long-running report or cursor displaying query results could block cleanup of dead rows, bloating all volatile tables in the database. The only options were to allow the bloat, suspend normal updates to other tables, or kill the long-running activity -- which might be completely unrelated to the bloating tables. Accumulation of bloat could cause performance problems and excessive use of storage space.<br />
<br />
A new configuration option called old_snapshot_threshold allows the cluster to be configured to allow cleanup of a dead row when the transaction which updated or deleted it (causing it to be dead) has completed and all snapshots which can still see it have reached a certain age, without immediately terminating activities which are using such snapshots. If, for example, a large monthly report is running off of data in table etl_monthly (which is not currently changing), bloat in other tables will be limited, and the report can run to completion without error. If a snapshot has passed the threshold and a query uses that snapshot to attempt to read data from a page modified recently enough that it might not produce accurate results, then a "snapshot too old" error will be thrown. Normally the goal in configuring old_snapshot_threshold is to set it high enough that such an error is rarely seen, while preventing problems caused by bloat.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aocLh-0006C7-2W@gemulon.postgresql.org Add the "snapshot too old" feature ]<br />
<br />
== psql ==<br />
<br />
=== \ev and \sv commands to edit views ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/07/21/waiting-for-9-6-add-psql-ev-and-sv-commands-for-editing-and-showing-view-definitions/ Waiting for 9.6 – Add psql \ev and \sv commands for editing and showing view definitions.]<br />
<br />
=== Prompt variable to show PId of backend ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/17/waiting-for-9-6-add-psql-prompt-variable-showing-the-pid-of-the-connected-to-backend/ Waiting for 9.6 – Add psql PROMPT variable showing the pid of the connected to backend.]<br />
<br />
=== Multiple -c and -f options ===<br />
<br />
* [https://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ support for multiple -c and -f options]<br />
<br />
=== Crosstabs in psql ===<br />
<br />
\crosstabview is a completely different way to display results from a<br />
query: instead of a vertical display of rows, the data values are placed<br />
in a grid where the column and row headers come from the data itself,<br />
similar to a spreadsheet.<br />
<br />
* [https://www.depesz.com/2016/04/27/waiting-for-9-6-support-crosstabview-in-psql/ Waiting for 9.6: Crosstabs in psql]<br />
<br />
== SQL commands ==<br />
<br />
=== ALTER TABLE ADD COLUMN IF NOT EXISTS ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/19/waiting-for-9-6-add-if-not-exists-processing-to-alter-table-add-column/ Waiting for 9.6 – Add IF NOT EXISTS processing to ALTER TABLE ADD COLUMN]<br />
<br />
=== ALTER TABLE SET and its locks ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-lower-locks-alter-table-set/ Lock reductions for ALTER TABLE SET]<br />
<br />
== Other Features ==<br />
<br />
=== Extension cascade support to install dependencies ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZiPzU-0004m0-Lq@gemulon.postgresql.org Add CASCADE support for CREATE EXTENSION. ]<br />
<br />
=== Cube extension kNN support ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1a9tQP-0004Qd-R7@gemulon.postgresql.org Cube extension kNN support ]<br />
<br />
<br />
=== Command progress reporting ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adhjH-0008RE-TV@gemulon.postgresql.org Add a generic command progress reporting facility. ]<br />
* [http://www.postgresql.org/message-id/E1afsqY-0003qB-Mb@gemulon.postgresql.org Add simple VACUUM progress reporting. ]<br />
* [https://www.depesz.com/2016/03/09/waiting-for-9-6-add-a-generic-command-progress-reporting-facility/ Waiting for 9.6 – Add a generic command progress reporting facility.]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-add-simple-vacuum-progress-reporting/ Waiting for 9.6 – Add simple VACUUM progress reporting.]<br />
<br />
=== Detailed wait information in pg_stat_activity ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae5kR-0007wV-LY@gemulon.postgresql.org Provide much better wait information in pg_stat_activity. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wait-events/ Postgres 9.6 highlight - Tracking of wait events]<br />
<br />
=== Index-only scans for partial indexes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1alhet-0001o8-Hg@gemulon.postgresql.org Support using index-only scans with partial indexes in more case ]<br />
<br />
=== Performance improvements for external sort operations ===<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1aoQ56-0001hD-SR@gemulon.postgresql.org Use quicksort, not replacement selection, for external sorting ]<br />
<br />
* [http://www.postgresql.org/message-id/E1ageG4-0001Sj-RW@gemulon.postgresql.org Improve memory management for external sorts ]<br />
<br />
=== Phrase full text search ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aoCJy-0004bp-HI@gemulon.postgresql.org Phrase full text search. ]<br />
* [https://lwn.net/Articles/689387/ pgCon and PostgreSQL 9.6]<br />
<br />
=== pg_basebackup extended with replication slots ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-base-backup-slot/ Postgres 9.6 feature highlight - pg_basebackup and replication slots]<br />
<br />
=== Replication slots can allocate WAL at creation ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-replication-slot-improvements/ Postgres 9.6 feature highlight - Replication slot improvements]<br />
<br />
=== New API for hot physical backups ===<br />
<br />
Prior to PostgreSQL 9.6, the only way to perform concurrent physical backups was through pg_basebackup, via the streaming replication protocol. Low-level file system copy was only available in an exclusive mode, by calling pg_start_backup(), initiating the copy of data files, then finally calling pg_stop_backup().<br />
<br />
The limitation of taking one backup at a time has been overcome by a new native API which redefines the pg_start_backup() method and adds a variant to pg_stop_backup(). For back-compatibility, the older signatures have been kept.<br />
<br />
The new pg_start_backup function now accepts a third optional parameter, called 'exclusive', which is set by default to 'true' for backward compatibility.<br />
Initiating a concurrent (or if you prefer, a non-exclusive) backup is rather simple:<br />
<br />
SELECT pg_start_backup('my_label', false, false);<br />
<br />
If you are not familiar with pg_start_backup(), the first argument is a label for the backup, while the second is a request for a fast checkpoint operation. The third parameter, when set to false, requests a concurrent backup:<br />
<br />
postgres=# SELECT pg_start_backup('my_label', true, false);<br />
-[ RECORD 1 ]---+----------<br />
pg_start_backup | 0/F000028<br />
<br />
The PostgreSQL connection requesting the concurrent backup needs to remain active for the whole duration of the physical copy of data files (performed with your favourite tools such as rsync, cp, tar, SAN or LVM snapshots, ...). '''Note:''' this operation follows the same procedure as with prior versions of PostgreSQL (for detailed information, please refer to the documentation about continuous archiving and Point-In-Time-Recovery).<br />
<br />
When finished, we need to use the new version of pg_stop_backup() to specify that we are closing the current non-exclusive backup:<br />
<br />
SELECT * FROM pg_stop_backup(false);<br />
<br />
The different signature has a mandatory parameter, called 'exclusive', which<br />
needs to be set to 'false' for concurrent backup. The reason is that the function returns a different result, a row made up of three fields:<br />
<br />
# LSN, for backup consistency, returned at pg_stop_backup() time: identical to the previous version<br />
# the content of the label file: this needs to be saved as 'backup_label' in the main backup directory (new in 9.6)<br />
# the list of tablespaces: if not empty, this needs to be saved as 'tablespace_map' in the main backup directory (new in 9.6)<br />
<br />
For example:<br />
<br />
postgres=# SELECT * FROM pg_stop_backup(false);<br />
NOTICE: pg_stop_backup complete, all required WAL segments have been archived<br />
-[ RECORD 1 ]-------------------------------------------------------------<br />
lsn | 0/F000130<br />
labelfile | START WAL LOCATION: 0/F000028 (file 00000001000000000000000F)+<br />
| CHECKPOINT LOCATION: 0/F000060 +<br />
| BACKUP METHOD: streamed +<br />
| BACKUP FROM: master +<br />
| START TIME: 2016-05-16 09:19:44 CEST +<br />
| LABEL: my_label +<br />
| <br />
spcmapfile | 16386 /Users/gabriele/pg96/tbs1 +<br />
| 16388 /Users/gabriele/pg96/tbs2 +<br />
| <br />
<br />
As you can see, these two steps require users to change their customised backup scripts. However, users should expect common disaster recovery and backup external solutions such as [http://www.pgbarman.org/ Barman], [https://github.com/omniti-labs/omnipitr OmniPITR], [http://www.pgbackrest.org/ PgBackRest], [https://github.com/ohmu/pghoard pghoard], [https://github.com/wal-e/wal-e WAL-E] to transparently manage this new behaviour introduced in 9.6.<br />
<br />
This new in-core API replaces the pgespresso package that was previously used with Barman 1.3.1 and above. Barman 2.0 now supports both pgespresso for PG9.2-PG9.5 and the new 9.6 API.<br />
<br />
'''IMPORTANT:''' this new API will become the only supported way in the future to coordinate low level backup operations with PostgreSQL.<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1anVSA-0002zm-Gc@gemulon.postgresql.org Implement backup API functions for non-exclusive backups]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-non-exclusive-backup/ Postgres 9.6 highlight - Non-exclusive base backups]<br />
<br />
=== COPY and DML statements (CTEs) ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-copy-dml-statements/ COPY and DML statements]<br />
<br />
=== Generic WAL facility ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-generic-wal-interface/ Postgres 9.6 highlight - Generic WAL interface]<br />
<br />
=== pg_blocking_pids ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-blocking-pids/ Postgres 9.6 highlight - pg_blocking_pids]<br />
<br />
=== Functions pg_get_* to return NULL on invalid objects ===<br />
<br />
Up to 9.6, such functions could have easily bumped on "cache lookup" errors.<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-behavior-change-pg-get/ Upcoming changes for pg_get functions on invalid objects]<br />
<br />
=== pg_notification_queue_usage to look at notify queue ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/18/waiting-for-9-6-add-new-function-pg_notification_queue_usage/ Waiting for 9.6 – Add new function pg_notification_queue_usage.]<br />
<br />
=== Extensions: CASCADE support ===<br />
<br />
* [https://www.depesz.com/2015/10/08/waiting-for-9-6-add-cascade-support-for-create-extension/ Waiting for 9.6 – Add CASCADE support for CREATE EXTENSION]<br />
<br />
=== Trigonometric functions in degrees ===<br />
<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-add-trigonometric-functions-that-work-in-degrees/ Waiting for 9.6 – Add trigonometric functions that work in degrees.]<br />
<br />
=== New system view pg_config ===<br />
<br />
* [https://www.depesz.com/2016/02/29/waiting-for-9-6-add-new-system-view-pg_config/ Waiting for 9.6 – Add new system view, pg_config]</div>Agliohttps://wiki.postgresql.org/index.php?title=NewIn96&diff=28267NewIn962016-09-28T18:33:03Z<p>Aglio: /* Parallel sequential scans */</p>
<hr />
<div>= What's New in PostgreSQL 9.6 =<br />
<br />
This page is a work in progress which will include details of PostgreSQL 9.6 features and changes. Many thanks to Thom Brown for assembling the original list.<br />
<br />
== Parallel Query ==<br />
<br />
=== Parallel sequential scans ===<br />
<br />
PostgreSQL can now execute a full table scan in multiple parallel processes, up to the limits set by the user.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZwVzN-0000Xz-5e@gemulon.postgresql.org Generate parallel sequential scan plans in simple cases. ]<br />
* [https://www.depesz.com/2015/11/17/waiting-for-9-6-generate-parallel-sequential-scan-plans-in-simple-cases/ Waiting for 9.6 – Generate parallel sequential scan plans in simple cases.]<br />
* [https://lwn.net/Articles/689387/ pgCon and PostgreSQL 9.6]<br />
<br />
=== parallel joins ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aLyct-000314-UZ@gemulon.postgresql.org Support parallel joins, and make related improvements. ]<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-support-parallel-joins-and-make-related-improvements/ Waiting for 9.6 – Support parallel joins, and make related improvements.]<br />
<br />
=== parallel aggregates ===<br />
<br />
Parallel Aggregates allow aggregate functions to be processed concurrently by multiple worker processes. This can significantly increase the response times for queries aggregating large amounts of tuples down to just a few aggregate groups, providing that the server has enough otherwise idle CPUs and would otherwise be bounded by the single CPU which the backend process is running on. Each worker process operates on a subset of tuples and creates a partially aggregated result to which it returns to the main backend process where each partial result will be combined with ones from the other worker processes and the final aggregate result produced.<br />
<br />
Most internal aggregate functions support parallel mode. User defined aggregates will need to be changed to add a combine function, and possible a serialization and deserialization in the case of aggregate functions which return an INTERNAL state.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ahzxY-0004qA-GJ@gemulon.postgresql.org Support parallel aggregation. ]<br />
* [https://www.postgresql.org/docs/9.6/static/functions-aggregate.html Supported built-in aggregate functions. ]<br />
* [https://www.depesz.com/2016/03/23/waiting-for-9-6-support-parallel-aggregation/ Waiting for 9.6 – Support parallel aggregation.]<br />
<br />
== postgres_fdw ==<br />
<br />
=== Sort pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aBS4o-0002l1-Tv@gemulon.postgresql.org postgres_fdw: postgres_fdw: Consider requesting sorted data so we can do a merge join. ]<br />
<br />
=== join pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aTDlV-0007xw-Vj@gemulon.postgresql.org postgres_fdw: Push down joins to remote servers. ]<br />
<br />
=== DML (UPDATE/DELETE) pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1agzA4-00074P-QW@gemulon.postgresql.org Directly modify foreign tables. ]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-directly-modify-foreign-tables/ Waiting for 9.6 – Directly modify foreign tables.]<br />
<br />
=== Operator and function pushdown ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pushdown-improvements-postgres-fdw/ Operator and function pushdown with postgres_fdw]<br />
<br />
== Replication ==<br />
<br />
=== New remote_apply replication mode which waits for confirmation that a standby has applied changes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1al4z1-0004qD-GW@gemulon.postgresql.org Add new replication mode synchronous_commit = 'remote_apply'. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-remote-apply/ Postgres 9.6 highlight - remote_apply]<br />
<br />
=== Support for multiple synchronous standbys ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aniiT-00083J-4W@gemulon.postgresql.org Support multiple synchronous standby servers. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-multi-sync-rep/ Postgres 9.6 highlight - multi-sync standbys]<br />
<br />
=== pg_stat_wal_receiver ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wal-receiver-status/ WAL receiver status view]<br />
<br />
== Transactions, VACUUM and the Visibility Map ==<br />
<br />
=== pg_visibility extension for examining visibility maps ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adHwi-0007KB-TM@gemulon.postgresql.org Add pg_visibility contrib module. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-visibility/ Postgres 9.6 highlight - pg_visibility]<br />
<br />
=== Frozen page data in visibility map for skipping vacuum on already-frozen data ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae7wj-0001mM-Ib@gemulon.postgresql.org Don't vacuum all-frozen pages. ]<br />
<br />
=== User-defined expiration of snapshots to control table bloat ===<br />
<br />
Until now a long-running report or cursor displaying query results could block cleanup of dead rows, bloating all volatile tables in the database. The only options were to allow the bloat, suspend normal updates to other tables, or kill the long-running activity -- which might be completely unrelated to the bloating tables. Accumulation of bloat could cause performance problems and excessive use of storage space.<br />
<br />
A new configuration option called old_snapshot_threshold allows the cluster to be configured to allow cleanup of a dead row when the transaction which updated or deleted it (causing it to be dead) has completed and all snapshots which can still see it have reached a certain age, without immediately terminating activities which are using such snapshots. If, for example, a large monthly report is running off of data in table etl_monthly (which is not currently changing), bloat in other tables will be limited, and the report can run to completion without error. If a snapshot has passed the threshold and a query uses that snapshot to attempt to read data from a page modified recently enough that it might not produce accurate results, then a "snapshot too old" error will be thrown. Normally the goal in configuring old_snapshot_threshold is to set it high enough that such an error is rarely seen, while preventing problems caused by bloat.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aocLh-0006C7-2W@gemulon.postgresql.org Add the "snapshot too old" feature ]<br />
<br />
== psql ==<br />
<br />
=== \ev and \sv commands to edit views ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/07/21/waiting-for-9-6-add-psql-ev-and-sv-commands-for-editing-and-showing-view-definitions/ Waiting for 9.6 – Add psql \ev and \sv commands for editing and showing view definitions.]<br />
<br />
=== Prompt variable to show PId of backend ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/17/waiting-for-9-6-add-psql-prompt-variable-showing-the-pid-of-the-connected-to-backend/ Waiting for 9.6 – Add psql PROMPT variable showing the pid of the connected to backend.]<br />
<br />
=== Multiple -c and -f options ===<br />
<br />
* [https://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ support for multiple -c and -f options]<br />
<br />
=== Crosstabs in psql ===<br />
<br />
\crosstabview is a completely different way to display results from a<br />
query: instead of a vertical display of rows, the data values are placed<br />
in a grid where the column and row headers come from the data itself,<br />
similar to a spreadsheet.<br />
<br />
* [https://www.depesz.com/2016/04/27/waiting-for-9-6-support-crosstabview-in-psql/ Waiting for 9.6: Crosstabs in psql]<br />
<br />
== SQL commands ==<br />
<br />
=== ALTER TABLE ADD COLUMN IF NOT EXISTS ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/19/waiting-for-9-6-add-if-not-exists-processing-to-alter-table-add-column/ Waiting for 9.6 – Add IF NOT EXISTS processing to ALTER TABLE ADD COLUMN]<br />
<br />
=== ALTER TABLE SET and its locks ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-lower-locks-alter-table-set/ Lock reductions for ALTER TABLE SET]<br />
<br />
== Other Features ==<br />
<br />
=== Extension cascade support to install dependencies ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZiPzU-0004m0-Lq@gemulon.postgresql.org Add CASCADE support for CREATE EXTENSION. ]<br />
<br />
=== Cube extension kNN support ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1a9tQP-0004Qd-R7@gemulon.postgresql.org Cube extension kNN support ]<br />
<br />
<br />
=== Command progress reporting ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adhjH-0008RE-TV@gemulon.postgresql.org Add a generic command progress reporting facility. ]<br />
* [http://www.postgresql.org/message-id/E1afsqY-0003qB-Mb@gemulon.postgresql.org Add simple VACUUM progress reporting. ]<br />
* [https://www.depesz.com/2016/03/09/waiting-for-9-6-add-a-generic-command-progress-reporting-facility/ Waiting for 9.6 – Add a generic command progress reporting facility.]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-add-simple-vacuum-progress-reporting/ Waiting for 9.6 – Add simple VACUUM progress reporting.]<br />
<br />
=== Detailed wait information in pg_stat_activity ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae5kR-0007wV-LY@gemulon.postgresql.org Provide much better wait information in pg_stat_activity. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wait-events/ Postgres 9.6 highlight - Tracking of wait events]<br />
<br />
=== Index-only scans for partial indexes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1alhet-0001o8-Hg@gemulon.postgresql.org Support using index-only scans with partial indexes in more case ]<br />
<br />
=== Performance improvements for external sort operations ===<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1aoQ56-0001hD-SR@gemulon.postgresql.org Use quicksort, not replacement selection, for external sorting ]<br />
<br />
* [http://www.postgresql.org/message-id/E1ageG4-0001Sj-RW@gemulon.postgresql.org Improve memory management for external sorts ]<br />
<br />
=== Phrase full text search ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aoCJy-0004bp-HI@gemulon.postgresql.org Phrase full text search. ]<br />
<br />
=== pg_basebackup extended with replication slots ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-base-backup-slot/ Postgres 9.6 feature highlight - pg_basebackup and replication slots]<br />
<br />
=== Replication slots can allocate WAL at creation ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-replication-slot-improvements/ Postgres 9.6 feature highlight - Replication slot improvements]<br />
<br />
=== New API for hot physical backups ===<br />
<br />
Prior to PostgreSQL 9.6, the only way to perform concurrent physical backups was through pg_basebackup, via the streaming replication protocol. Low-level file system copy was only available in an exclusive mode, by calling pg_start_backup(), initiating the copy of data files, then finally calling pg_stop_backup().<br />
<br />
The limitation of taking one backup at a time has been overcome by a new native API which redefines the pg_start_backup() method and adds a variant to pg_stop_backup(). For back-compatibility, the older signatures have been kept.<br />
<br />
The new pg_start_backup function now accepts a third optional parameter, called 'exclusive', which is set by default to 'true' for backward compatibility.<br />
Initiating a concurrent (or if you prefer, a non-exclusive) backup is rather simple:<br />
<br />
SELECT pg_start_backup('my_label', false, false);<br />
<br />
If you are not familiar with pg_start_backup(), the first argument is a label for the backup, while the second is a request for a fast checkpoint operation. The third parameter, when set to false, requests a concurrent backup:<br />
<br />
postgres=# SELECT pg_start_backup('my_label', true, false);<br />
-[ RECORD 1 ]---+----------<br />
pg_start_backup | 0/F000028<br />
<br />
The PostgreSQL connection requesting the concurrent backup needs to remain active for the whole duration of the physical copy of data files (performed with your favourite tools such as rsync, cp, tar, SAN or LVM snapshots, ...). '''Note:''' this operation follows the same procedure as with prior versions of PostgreSQL (for detailed information, please refer to the documentation about continuous archiving and Point-In-Time-Recovery).<br />
<br />
When finished, we need to use the new version of pg_stop_backup() to specify that we are closing the current non-exclusive backup:<br />
<br />
SELECT * FROM pg_stop_backup(false);<br />
<br />
The different signature has a mandatory parameter, called 'exclusive', which<br />
needs to be set to 'false' for concurrent backup. The reason is that the function returns a different result, a row made up of three fields:<br />
<br />
# LSN, for backup consistency, returned at pg_stop_backup() time: identical to the previous version<br />
# the content of the label file: this needs to be saved as 'backup_label' in the main backup directory (new in 9.6)<br />
# the list of tablespaces: if not empty, this needs to be saved as 'tablespace_map' in the main backup directory (new in 9.6)<br />
<br />
For example:<br />
<br />
postgres=# SELECT * FROM pg_stop_backup(false);<br />
NOTICE: pg_stop_backup complete, all required WAL segments have been archived<br />
-[ RECORD 1 ]-------------------------------------------------------------<br />
lsn | 0/F000130<br />
labelfile | START WAL LOCATION: 0/F000028 (file 00000001000000000000000F)+<br />
| CHECKPOINT LOCATION: 0/F000060 +<br />
| BACKUP METHOD: streamed +<br />
| BACKUP FROM: master +<br />
| START TIME: 2016-05-16 09:19:44 CEST +<br />
| LABEL: my_label +<br />
| <br />
spcmapfile | 16386 /Users/gabriele/pg96/tbs1 +<br />
| 16388 /Users/gabriele/pg96/tbs2 +<br />
| <br />
<br />
As you can see, these two steps require users to change their customised backup scripts. However, users should expect common disaster recovery and backup external solutions such as [http://www.pgbarman.org/ Barman], [https://github.com/omniti-labs/omnipitr OmniPITR], [http://www.pgbackrest.org/ PgBackRest], [https://github.com/ohmu/pghoard pghoard], [https://github.com/wal-e/wal-e WAL-E] to transparently manage this new behaviour introduced in 9.6.<br />
<br />
This new in-core API replaces the pgespresso package that was previously used with Barman 1.3.1 and above. Barman 2.0 now supports both pgespresso for PG9.2-PG9.5 and the new 9.6 API.<br />
<br />
'''IMPORTANT:''' this new API will become the only supported way in the future to coordinate low level backup operations with PostgreSQL.<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1anVSA-0002zm-Gc@gemulon.postgresql.org Implement backup API functions for non-exclusive backups]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-non-exclusive-backup/ Postgres 9.6 highlight - Non-exclusive base backups]<br />
<br />
=== COPY and DML statements (CTEs) ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-copy-dml-statements/ COPY and DML statements]<br />
<br />
=== Generic WAL facility ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-generic-wal-interface/ Postgres 9.6 highlight - Generic WAL interface]<br />
<br />
=== pg_blocking_pids ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-blocking-pids/ Postgres 9.6 highlight - pg_blocking_pids]<br />
<br />
=== Functions pg_get_* to return NULL on invalid objects ===<br />
<br />
Up to 9.6, such functions could have easily bumped on "cache lookup" errors.<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-behavior-change-pg-get/ Upcoming changes for pg_get functions on invalid objects]<br />
<br />
=== pg_notification_queue_usage to look at notify queue ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/18/waiting-for-9-6-add-new-function-pg_notification_queue_usage/ Waiting for 9.6 – Add new function pg_notification_queue_usage.]<br />
<br />
=== Extensions: CASCADE support ===<br />
<br />
* [https://www.depesz.com/2015/10/08/waiting-for-9-6-add-cascade-support-for-create-extension/ Waiting for 9.6 – Add CASCADE support for CREATE EXTENSION]<br />
<br />
=== Trigonometric functions in degrees ===<br />
<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-add-trigonometric-functions-that-work-in-degrees/ Waiting for 9.6 – Add trigonometric functions that work in degrees.]<br />
<br />
=== New system view pg_config ===<br />
<br />
* [https://www.depesz.com/2016/02/29/waiting-for-9-6-add-new-system-view-pg_config/ Waiting for 9.6 – Add new system view, pg_config]</div>Agliohttps://wiki.postgresql.org/index.php?title=NewIn96&diff=28266NewIn962016-09-28T18:29:50Z<p>Aglio: /* Crosstabs in psql */</p>
<hr />
<div>= What's New in PostgreSQL 9.6 =<br />
<br />
This page is a work in progress which will include details of PostgreSQL 9.6 features and changes. Many thanks to Thom Brown for assembling the original list.<br />
<br />
== Parallel Query ==<br />
<br />
=== Parallel sequential scans ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZwVzN-0000Xz-5e@gemulon.postgresql.org Generate parallel sequential scan plans in simple cases. ]<br />
* [https://www.depesz.com/2015/11/17/waiting-for-9-6-generate-parallel-sequential-scan-plans-in-simple-cases/ Waiting for 9.6 – Generate parallel sequential scan plans in simple cases.]<br />
<br />
=== parallel joins ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aLyct-000314-UZ@gemulon.postgresql.org Support parallel joins, and make related improvements. ]<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-support-parallel-joins-and-make-related-improvements/ Waiting for 9.6 – Support parallel joins, and make related improvements.]<br />
<br />
=== parallel aggregates ===<br />
<br />
Parallel Aggregates allow aggregate functions to be processed concurrently by multiple worker processes. This can significantly increase the response times for queries aggregating large amounts of tuples down to just a few aggregate groups, providing that the server has enough otherwise idle CPUs and would otherwise be bounded by the single CPU which the backend process is running on. Each worker process operates on a subset of tuples and creates a partially aggregated result to which it returns to the main backend process where each partial result will be combined with ones from the other worker processes and the final aggregate result produced.<br />
<br />
Most internal aggregate functions support parallel mode. User defined aggregates will need to be changed to add a combine function, and possible a serialization and deserialization in the case of aggregate functions which return an INTERNAL state.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ahzxY-0004qA-GJ@gemulon.postgresql.org Support parallel aggregation. ]<br />
* [https://www.postgresql.org/docs/9.6/static/functions-aggregate.html Supported built-in aggregate functions. ]<br />
* [https://www.depesz.com/2016/03/23/waiting-for-9-6-support-parallel-aggregation/ Waiting for 9.6 – Support parallel aggregation.]<br />
<br />
== postgres_fdw ==<br />
<br />
=== Sort pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aBS4o-0002l1-Tv@gemulon.postgresql.org postgres_fdw: postgres_fdw: Consider requesting sorted data so we can do a merge join. ]<br />
<br />
=== join pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aTDlV-0007xw-Vj@gemulon.postgresql.org postgres_fdw: Push down joins to remote servers. ]<br />
<br />
=== DML (UPDATE/DELETE) pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1agzA4-00074P-QW@gemulon.postgresql.org Directly modify foreign tables. ]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-directly-modify-foreign-tables/ Waiting for 9.6 – Directly modify foreign tables.]<br />
<br />
=== Operator and function pushdown ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pushdown-improvements-postgres-fdw/ Operator and function pushdown with postgres_fdw]<br />
<br />
== Replication ==<br />
<br />
=== New remote_apply replication mode which waits for confirmation that a standby has applied changes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1al4z1-0004qD-GW@gemulon.postgresql.org Add new replication mode synchronous_commit = 'remote_apply'. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-remote-apply/ Postgres 9.6 highlight - remote_apply]<br />
<br />
=== Support for multiple synchronous standbys ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aniiT-00083J-4W@gemulon.postgresql.org Support multiple synchronous standby servers. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-multi-sync-rep/ Postgres 9.6 highlight - multi-sync standbys]<br />
<br />
=== pg_stat_wal_receiver ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wal-receiver-status/ WAL receiver status view]<br />
<br />
== Transactions, VACUUM and the Visibility Map ==<br />
<br />
=== pg_visibility extension for examining visibility maps ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adHwi-0007KB-TM@gemulon.postgresql.org Add pg_visibility contrib module. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-visibility/ Postgres 9.6 highlight - pg_visibility]<br />
<br />
=== Frozen page data in visibility map for skipping vacuum on already-frozen data ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae7wj-0001mM-Ib@gemulon.postgresql.org Don't vacuum all-frozen pages. ]<br />
<br />
=== User-defined expiration of snapshots to control table bloat ===<br />
<br />
Until now a long-running report or cursor displaying query results could block cleanup of dead rows, bloating all volatile tables in the database. The only options were to allow the bloat, suspend normal updates to other tables, or kill the long-running activity -- which might be completely unrelated to the bloating tables. Accumulation of bloat could cause performance problems and excessive use of storage space.<br />
<br />
A new configuration option called old_snapshot_threshold allows the cluster to be configured to allow cleanup of a dead row when the transaction which updated or deleted it (causing it to be dead) has completed and all snapshots which can still see it have reached a certain age, without immediately terminating activities which are using such snapshots. If, for example, a large monthly report is running off of data in table etl_monthly (which is not currently changing), bloat in other tables will be limited, and the report can run to completion without error. If a snapshot has passed the threshold and a query uses that snapshot to attempt to read data from a page modified recently enough that it might not produce accurate results, then a "snapshot too old" error will be thrown. Normally the goal in configuring old_snapshot_threshold is to set it high enough that such an error is rarely seen, while preventing problems caused by bloat.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aocLh-0006C7-2W@gemulon.postgresql.org Add the "snapshot too old" feature ]<br />
<br />
== psql ==<br />
<br />
=== \ev and \sv commands to edit views ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/07/21/waiting-for-9-6-add-psql-ev-and-sv-commands-for-editing-and-showing-view-definitions/ Waiting for 9.6 – Add psql \ev and \sv commands for editing and showing view definitions.]<br />
<br />
=== Prompt variable to show PId of backend ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/17/waiting-for-9-6-add-psql-prompt-variable-showing-the-pid-of-the-connected-to-backend/ Waiting for 9.6 – Add psql PROMPT variable showing the pid of the connected to backend.]<br />
<br />
=== Multiple -c and -f options ===<br />
<br />
* [https://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ support for multiple -c and -f options]<br />
<br />
=== Crosstabs in psql ===<br />
<br />
\crosstabview is a completely different way to display results from a<br />
query: instead of a vertical display of rows, the data values are placed<br />
in a grid where the column and row headers come from the data itself,<br />
similar to a spreadsheet.<br />
<br />
* [https://www.depesz.com/2016/04/27/waiting-for-9-6-support-crosstabview-in-psql/ Waiting for 9.6: Crosstabs in psql]<br />
<br />
== SQL commands ==<br />
<br />
=== ALTER TABLE ADD COLUMN IF NOT EXISTS ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/19/waiting-for-9-6-add-if-not-exists-processing-to-alter-table-add-column/ Waiting for 9.6 – Add IF NOT EXISTS processing to ALTER TABLE ADD COLUMN]<br />
<br />
=== ALTER TABLE SET and its locks ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-lower-locks-alter-table-set/ Lock reductions for ALTER TABLE SET]<br />
<br />
== Other Features ==<br />
<br />
=== Extension cascade support to install dependencies ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZiPzU-0004m0-Lq@gemulon.postgresql.org Add CASCADE support for CREATE EXTENSION. ]<br />
<br />
=== Cube extension kNN support ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1a9tQP-0004Qd-R7@gemulon.postgresql.org Cube extension kNN support ]<br />
<br />
<br />
=== Command progress reporting ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adhjH-0008RE-TV@gemulon.postgresql.org Add a generic command progress reporting facility. ]<br />
* [http://www.postgresql.org/message-id/E1afsqY-0003qB-Mb@gemulon.postgresql.org Add simple VACUUM progress reporting. ]<br />
* [https://www.depesz.com/2016/03/09/waiting-for-9-6-add-a-generic-command-progress-reporting-facility/ Waiting for 9.6 – Add a generic command progress reporting facility.]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-add-simple-vacuum-progress-reporting/ Waiting for 9.6 – Add simple VACUUM progress reporting.]<br />
<br />
=== Detailed wait information in pg_stat_activity ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae5kR-0007wV-LY@gemulon.postgresql.org Provide much better wait information in pg_stat_activity. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wait-events/ Postgres 9.6 highlight - Tracking of wait events]<br />
<br />
=== Index-only scans for partial indexes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1alhet-0001o8-Hg@gemulon.postgresql.org Support using index-only scans with partial indexes in more case ]<br />
<br />
=== Performance improvements for external sort operations ===<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1aoQ56-0001hD-SR@gemulon.postgresql.org Use quicksort, not replacement selection, for external sorting ]<br />
<br />
* [http://www.postgresql.org/message-id/E1ageG4-0001Sj-RW@gemulon.postgresql.org Improve memory management for external sorts ]<br />
<br />
=== Phrase full text search ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aoCJy-0004bp-HI@gemulon.postgresql.org Phrase full text search. ]<br />
<br />
=== pg_basebackup extended with replication slots ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-base-backup-slot/ Postgres 9.6 feature highlight - pg_basebackup and replication slots]<br />
<br />
=== Replication slots can allocate WAL at creation ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-replication-slot-improvements/ Postgres 9.6 feature highlight - Replication slot improvements]<br />
<br />
=== New API for hot physical backups ===<br />
<br />
Prior to PostgreSQL 9.6, the only way to perform concurrent physical backups was through pg_basebackup, via the streaming replication protocol. Low-level file system copy was only available in an exclusive mode, by calling pg_start_backup(), initiating the copy of data files, then finally calling pg_stop_backup().<br />
<br />
The limitation of taking one backup at a time has been overcome by a new native API which redefines the pg_start_backup() method and adds a variant to pg_stop_backup(). For back-compatibility, the older signatures have been kept.<br />
<br />
The new pg_start_backup function now accepts a third optional parameter, called 'exclusive', which is set by default to 'true' for backward compatibility.<br />
Initiating a concurrent (or if you prefer, a non-exclusive) backup is rather simple:<br />
<br />
SELECT pg_start_backup('my_label', false, false);<br />
<br />
If you are not familiar with pg_start_backup(), the first argument is a label for the backup, while the second is a request for a fast checkpoint operation. The third parameter, when set to false, requests a concurrent backup:<br />
<br />
postgres=# SELECT pg_start_backup('my_label', true, false);<br />
-[ RECORD 1 ]---+----------<br />
pg_start_backup | 0/F000028<br />
<br />
The PostgreSQL connection requesting the concurrent backup needs to remain active for the whole duration of the physical copy of data files (performed with your favourite tools such as rsync, cp, tar, SAN or LVM snapshots, ...). '''Note:''' this operation follows the same procedure as with prior versions of PostgreSQL (for detailed information, please refer to the documentation about continuous archiving and Point-In-Time-Recovery).<br />
<br />
When finished, we need to use the new version of pg_stop_backup() to specify that we are closing the current non-exclusive backup:<br />
<br />
SELECT * FROM pg_stop_backup(false);<br />
<br />
The different signature has a mandatory parameter, called 'exclusive', which<br />
needs to be set to 'false' for concurrent backup. The reason is that the function returns a different result, a row made up of three fields:<br />
<br />
# LSN, for backup consistency, returned at pg_stop_backup() time: identical to the previous version<br />
# the content of the label file: this needs to be saved as 'backup_label' in the main backup directory (new in 9.6)<br />
# the list of tablespaces: if not empty, this needs to be saved as 'tablespace_map' in the main backup directory (new in 9.6)<br />
<br />
For example:<br />
<br />
postgres=# SELECT * FROM pg_stop_backup(false);<br />
NOTICE: pg_stop_backup complete, all required WAL segments have been archived<br />
-[ RECORD 1 ]-------------------------------------------------------------<br />
lsn | 0/F000130<br />
labelfile | START WAL LOCATION: 0/F000028 (file 00000001000000000000000F)+<br />
| CHECKPOINT LOCATION: 0/F000060 +<br />
| BACKUP METHOD: streamed +<br />
| BACKUP FROM: master +<br />
| START TIME: 2016-05-16 09:19:44 CEST +<br />
| LABEL: my_label +<br />
| <br />
spcmapfile | 16386 /Users/gabriele/pg96/tbs1 +<br />
| 16388 /Users/gabriele/pg96/tbs2 +<br />
| <br />
<br />
As you can see, these two steps require users to change their customised backup scripts. However, users should expect common disaster recovery and backup external solutions such as [http://www.pgbarman.org/ Barman], [https://github.com/omniti-labs/omnipitr OmniPITR], [http://www.pgbackrest.org/ PgBackRest], [https://github.com/ohmu/pghoard pghoard], [https://github.com/wal-e/wal-e WAL-E] to transparently manage this new behaviour introduced in 9.6.<br />
<br />
This new in-core API replaces the pgespresso package that was previously used with Barman 1.3.1 and above. Barman 2.0 now supports both pgespresso for PG9.2-PG9.5 and the new 9.6 API.<br />
<br />
'''IMPORTANT:''' this new API will become the only supported way in the future to coordinate low level backup operations with PostgreSQL.<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1anVSA-0002zm-Gc@gemulon.postgresql.org Implement backup API functions for non-exclusive backups]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-non-exclusive-backup/ Postgres 9.6 highlight - Non-exclusive base backups]<br />
<br />
=== COPY and DML statements (CTEs) ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-copy-dml-statements/ COPY and DML statements]<br />
<br />
=== Generic WAL facility ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-generic-wal-interface/ Postgres 9.6 highlight - Generic WAL interface]<br />
<br />
=== pg_blocking_pids ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-blocking-pids/ Postgres 9.6 highlight - pg_blocking_pids]<br />
<br />
=== Functions pg_get_* to return NULL on invalid objects ===<br />
<br />
Up to 9.6, such functions could have easily bumped on "cache lookup" errors.<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-behavior-change-pg-get/ Upcoming changes for pg_get functions on invalid objects]<br />
<br />
=== pg_notification_queue_usage to look at notify queue ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/18/waiting-for-9-6-add-new-function-pg_notification_queue_usage/ Waiting for 9.6 – Add new function pg_notification_queue_usage.]<br />
<br />
=== Extensions: CASCADE support ===<br />
<br />
* [https://www.depesz.com/2015/10/08/waiting-for-9-6-add-cascade-support-for-create-extension/ Waiting for 9.6 – Add CASCADE support for CREATE EXTENSION]<br />
<br />
=== Trigonometric functions in degrees ===<br />
<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-add-trigonometric-functions-that-work-in-degrees/ Waiting for 9.6 – Add trigonometric functions that work in degrees.]<br />
<br />
=== New system view pg_config ===<br />
<br />
* [https://www.depesz.com/2016/02/29/waiting-for-9-6-add-new-system-view-pg_config/ Waiting for 9.6 – Add new system view, pg_config]</div>Agliohttps://wiki.postgresql.org/index.php?title=NewIn96&diff=28265NewIn962016-09-28T18:29:12Z<p>Aglio: /* psql */</p>
<hr />
<div>= What's New in PostgreSQL 9.6 =<br />
<br />
This page is a work in progress which will include details of PostgreSQL 9.6 features and changes. Many thanks to Thom Brown for assembling the original list.<br />
<br />
== Parallel Query ==<br />
<br />
=== Parallel sequential scans ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZwVzN-0000Xz-5e@gemulon.postgresql.org Generate parallel sequential scan plans in simple cases. ]<br />
* [https://www.depesz.com/2015/11/17/waiting-for-9-6-generate-parallel-sequential-scan-plans-in-simple-cases/ Waiting for 9.6 – Generate parallel sequential scan plans in simple cases.]<br />
<br />
=== parallel joins ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aLyct-000314-UZ@gemulon.postgresql.org Support parallel joins, and make related improvements. ]<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-support-parallel-joins-and-make-related-improvements/ Waiting for 9.6 – Support parallel joins, and make related improvements.]<br />
<br />
=== parallel aggregates ===<br />
<br />
Parallel Aggregates allow aggregate functions to be processed concurrently by multiple worker processes. This can significantly increase the response times for queries aggregating large amounts of tuples down to just a few aggregate groups, providing that the server has enough otherwise idle CPUs and would otherwise be bounded by the single CPU which the backend process is running on. Each worker process operates on a subset of tuples and creates a partially aggregated result to which it returns to the main backend process where each partial result will be combined with ones from the other worker processes and the final aggregate result produced.<br />
<br />
Most internal aggregate functions support parallel mode. User defined aggregates will need to be changed to add a combine function, and possible a serialization and deserialization in the case of aggregate functions which return an INTERNAL state.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ahzxY-0004qA-GJ@gemulon.postgresql.org Support parallel aggregation. ]<br />
* [https://www.postgresql.org/docs/9.6/static/functions-aggregate.html Supported built-in aggregate functions. ]<br />
* [https://www.depesz.com/2016/03/23/waiting-for-9-6-support-parallel-aggregation/ Waiting for 9.6 – Support parallel aggregation.]<br />
<br />
== postgres_fdw ==<br />
<br />
=== Sort pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aBS4o-0002l1-Tv@gemulon.postgresql.org postgres_fdw: postgres_fdw: Consider requesting sorted data so we can do a merge join. ]<br />
<br />
=== join pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aTDlV-0007xw-Vj@gemulon.postgresql.org postgres_fdw: Push down joins to remote servers. ]<br />
<br />
=== DML (UPDATE/DELETE) pushdown ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1agzA4-00074P-QW@gemulon.postgresql.org Directly modify foreign tables. ]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-directly-modify-foreign-tables/ Waiting for 9.6 – Directly modify foreign tables.]<br />
<br />
=== Operator and function pushdown ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pushdown-improvements-postgres-fdw/ Operator and function pushdown with postgres_fdw]<br />
<br />
== Replication ==<br />
<br />
=== New remote_apply replication mode which waits for confirmation that a standby has applied changes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1al4z1-0004qD-GW@gemulon.postgresql.org Add new replication mode synchronous_commit = 'remote_apply'. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-remote-apply/ Postgres 9.6 highlight - remote_apply]<br />
<br />
=== Support for multiple synchronous standbys ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aniiT-00083J-4W@gemulon.postgresql.org Support multiple synchronous standby servers. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-multi-sync-rep/ Postgres 9.6 highlight - multi-sync standbys]<br />
<br />
=== pg_stat_wal_receiver ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wal-receiver-status/ WAL receiver status view]<br />
<br />
== Transactions, VACUUM and the Visibility Map ==<br />
<br />
=== pg_visibility extension for examining visibility maps ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adHwi-0007KB-TM@gemulon.postgresql.org Add pg_visibility contrib module. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-visibility/ Postgres 9.6 highlight - pg_visibility]<br />
<br />
=== Frozen page data in visibility map for skipping vacuum on already-frozen data ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae7wj-0001mM-Ib@gemulon.postgresql.org Don't vacuum all-frozen pages. ]<br />
<br />
=== User-defined expiration of snapshots to control table bloat ===<br />
<br />
Until now a long-running report or cursor displaying query results could block cleanup of dead rows, bloating all volatile tables in the database. The only options were to allow the bloat, suspend normal updates to other tables, or kill the long-running activity -- which might be completely unrelated to the bloating tables. Accumulation of bloat could cause performance problems and excessive use of storage space.<br />
<br />
A new configuration option called old_snapshot_threshold allows the cluster to be configured to allow cleanup of a dead row when the transaction which updated or deleted it (causing it to be dead) has completed and all snapshots which can still see it have reached a certain age, without immediately terminating activities which are using such snapshots. If, for example, a large monthly report is running off of data in table etl_monthly (which is not currently changing), bloat in other tables will be limited, and the report can run to completion without error. If a snapshot has passed the threshold and a query uses that snapshot to attempt to read data from a page modified recently enough that it might not produce accurate results, then a "snapshot too old" error will be thrown. Normally the goal in configuring old_snapshot_threshold is to set it high enough that such an error is rarely seen, while preventing problems caused by bloat.<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aocLh-0006C7-2W@gemulon.postgresql.org Add the "snapshot too old" feature ]<br />
<br />
== psql ==<br />
<br />
=== \ev and \sv commands to edit views ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/07/21/waiting-for-9-6-add-psql-ev-and-sv-commands-for-editing-and-showing-view-definitions/ Waiting for 9.6 – Add psql \ev and \sv commands for editing and showing view definitions.]<br />
<br />
=== Prompt variable to show PId of backend ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/17/waiting-for-9-6-add-psql-prompt-variable-showing-the-pid-of-the-connected-to-backend/ Waiting for 9.6 – Add psql PROMPT variable showing the pid of the connected to backend.]<br />
<br />
=== Multiple -c and -f options ===<br />
<br />
* [https://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ support for multiple -c and -f options]<br />
<br />
=== Crosstabs in psql ===<br />
<br />
\crosstabview is a completely different way to display results from a<br />
query: instead of a vertical display of rows, the data values are placed<br />
in a grid where the column and row headers come from the data itself,<br />
similar to a spreadsheet.<br />
<br />
* [https://www.depesz.com/2016/04/27/waiting-for-9-6-support-crosstabview-in-psql/]<br />
<br />
== SQL commands ==<br />
<br />
=== ALTER TABLE ADD COLUMN IF NOT EXISTS ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/19/waiting-for-9-6-add-if-not-exists-processing-to-alter-table-add-column/ Waiting for 9.6 – Add IF NOT EXISTS processing to ALTER TABLE ADD COLUMN]<br />
<br />
=== ALTER TABLE SET and its locks ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-lower-locks-alter-table-set/ Lock reductions for ALTER TABLE SET]<br />
<br />
== Other Features ==<br />
<br />
=== Extension cascade support to install dependencies ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ZiPzU-0004m0-Lq@gemulon.postgresql.org Add CASCADE support for CREATE EXTENSION. ]<br />
<br />
=== Cube extension kNN support ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1a9tQP-0004Qd-R7@gemulon.postgresql.org Cube extension kNN support ]<br />
<br />
<br />
=== Command progress reporting ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1adhjH-0008RE-TV@gemulon.postgresql.org Add a generic command progress reporting facility. ]<br />
* [http://www.postgresql.org/message-id/E1afsqY-0003qB-Mb@gemulon.postgresql.org Add simple VACUUM progress reporting. ]<br />
* [https://www.depesz.com/2016/03/09/waiting-for-9-6-add-a-generic-command-progress-reporting-facility/ Waiting for 9.6 – Add a generic command progress reporting facility.]<br />
* [https://www.depesz.com/2016/03/22/waiting-for-9-6-add-simple-vacuum-progress-reporting/ Waiting for 9.6 – Add simple VACUUM progress reporting.]<br />
<br />
=== Detailed wait information in pg_stat_activity ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1ae5kR-0007wV-LY@gemulon.postgresql.org Provide much better wait information in pg_stat_activity. ]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-wait-events/ Postgres 9.6 highlight - Tracking of wait events]<br />
<br />
=== Index-only scans for partial indexes ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1alhet-0001o8-Hg@gemulon.postgresql.org Support using index-only scans with partial indexes in more case ]<br />
<br />
=== Performance improvements for external sort operations ===<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1aoQ56-0001hD-SR@gemulon.postgresql.org Use quicksort, not replacement selection, for external sorting ]<br />
<br />
* [http://www.postgresql.org/message-id/E1ageG4-0001Sj-RW@gemulon.postgresql.org Improve memory management for external sorts ]<br />
<br />
=== Phrase full text search ===<br />
<br />
Links: <br />
<br />
* [http://www.postgresql.org/message-id/E1aoCJy-0004bp-HI@gemulon.postgresql.org Phrase full text search. ]<br />
<br />
=== pg_basebackup extended with replication slots ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-base-backup-slot/ Postgres 9.6 feature highlight - pg_basebackup and replication slots]<br />
<br />
=== Replication slots can allocate WAL at creation ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-replication-slot-improvements/ Postgres 9.6 feature highlight - Replication slot improvements]<br />
<br />
=== New API for hot physical backups ===<br />
<br />
Prior to PostgreSQL 9.6, the only way to perform concurrent physical backups was through pg_basebackup, via the streaming replication protocol. Low-level file system copy was only available in an exclusive mode, by calling pg_start_backup(), initiating the copy of data files, then finally calling pg_stop_backup().<br />
<br />
The limitation of taking one backup at a time has been overcome by a new native API which redefines the pg_start_backup() method and adds a variant to pg_stop_backup(). For back-compatibility, the older signatures have been kept.<br />
<br />
The new pg_start_backup function now accepts a third optional parameter, called 'exclusive', which is set by default to 'true' for backward compatibility.<br />
Initiating a concurrent (or if you prefer, a non-exclusive) backup is rather simple:<br />
<br />
SELECT pg_start_backup('my_label', false, false);<br />
<br />
If you are not familiar with pg_start_backup(), the first argument is a label for the backup, while the second is a request for a fast checkpoint operation. The third parameter, when set to false, requests a concurrent backup:<br />
<br />
postgres=# SELECT pg_start_backup('my_label', true, false);<br />
-[ RECORD 1 ]---+----------<br />
pg_start_backup | 0/F000028<br />
<br />
The PostgreSQL connection requesting the concurrent backup needs to remain active for the whole duration of the physical copy of data files (performed with your favourite tools such as rsync, cp, tar, SAN or LVM snapshots, ...). '''Note:''' this operation follows the same procedure as with prior versions of PostgreSQL (for detailed information, please refer to the documentation about continuous archiving and Point-In-Time-Recovery).<br />
<br />
When finished, we need to use the new version of pg_stop_backup() to specify that we are closing the current non-exclusive backup:<br />
<br />
SELECT * FROM pg_stop_backup(false);<br />
<br />
The different signature has a mandatory parameter, called 'exclusive', which<br />
needs to be set to 'false' for concurrent backup. The reason is that the function returns a different result, a row made up of three fields:<br />
<br />
# LSN, for backup consistency, returned at pg_stop_backup() time: identical to the previous version<br />
# the content of the label file: this needs to be saved as 'backup_label' in the main backup directory (new in 9.6)<br />
# the list of tablespaces: if not empty, this needs to be saved as 'tablespace_map' in the main backup directory (new in 9.6)<br />
<br />
For example:<br />
<br />
postgres=# SELECT * FROM pg_stop_backup(false);<br />
NOTICE: pg_stop_backup complete, all required WAL segments have been archived<br />
-[ RECORD 1 ]-------------------------------------------------------------<br />
lsn | 0/F000130<br />
labelfile | START WAL LOCATION: 0/F000028 (file 00000001000000000000000F)+<br />
| CHECKPOINT LOCATION: 0/F000060 +<br />
| BACKUP METHOD: streamed +<br />
| BACKUP FROM: master +<br />
| START TIME: 2016-05-16 09:19:44 CEST +<br />
| LABEL: my_label +<br />
| <br />
spcmapfile | 16386 /Users/gabriele/pg96/tbs1 +<br />
| 16388 /Users/gabriele/pg96/tbs2 +<br />
| <br />
<br />
As you can see, these two steps require users to change their customised backup scripts. However, users should expect common disaster recovery and backup external solutions such as [http://www.pgbarman.org/ Barman], [https://github.com/omniti-labs/omnipitr OmniPITR], [http://www.pgbackrest.org/ PgBackRest], [https://github.com/ohmu/pghoard pghoard], [https://github.com/wal-e/wal-e WAL-E] to transparently manage this new behaviour introduced in 9.6.<br />
<br />
This new in-core API replaces the pgespresso package that was previously used with Barman 1.3.1 and above. Barman 2.0 now supports both pgespresso for PG9.2-PG9.5 and the new 9.6 API.<br />
<br />
'''IMPORTANT:''' this new API will become the only supported way in the future to coordinate low level backup operations with PostgreSQL.<br />
<br />
Links:<br />
<br />
* [http://www.postgresql.org/message-id/E1anVSA-0002zm-Gc@gemulon.postgresql.org Implement backup API functions for non-exclusive backups]<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-non-exclusive-backup/ Postgres 9.6 highlight - Non-exclusive base backups]<br />
<br />
=== COPY and DML statements (CTEs) ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-copy-dml-statements/ COPY and DML statements]<br />
<br />
=== Generic WAL facility ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-generic-wal-interface/ Postgres 9.6 highlight - Generic WAL interface]<br />
<br />
=== pg_blocking_pids ===<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-feature-highlight-pg-blocking-pids/ Postgres 9.6 highlight - pg_blocking_pids]<br />
<br />
=== Functions pg_get_* to return NULL on invalid objects ===<br />
<br />
Up to 9.6, such functions could have easily bumped on "cache lookup" errors.<br />
<br />
Links:<br />
<br />
* [http://paquier.xyz/postgresql-2/postgres-9-6-behavior-change-pg-get/ Upcoming changes for pg_get functions on invalid objects]<br />
<br />
=== pg_notification_queue_usage to look at notify queue ===<br />
<br />
Links:<br />
<br />
* [https://www.depesz.com/2015/08/18/waiting-for-9-6-add-new-function-pg_notification_queue_usage/ Waiting for 9.6 – Add new function pg_notification_queue_usage.]<br />
<br />
=== Extensions: CASCADE support ===<br />
<br />
* [https://www.depesz.com/2015/10/08/waiting-for-9-6-add-cascade-support-for-create-extension/ Waiting for 9.6 – Add CASCADE support for CREATE EXTENSION]<br />
<br />
=== Trigonometric functions in degrees ===<br />
<br />
* [https://www.depesz.com/2016/02/01/waiting-for-9-6-add-trigonometric-functions-that-work-in-degrees/ Waiting for 9.6 – Add trigonometric functions that work in degrees.]<br />
<br />
=== New system view pg_config ===<br />
<br />
* [https://www.depesz.com/2016/02/29/waiting-for-9-6-add-new-system-view-pg_config/ Waiting for 9.6 – Add new system view, pg_config]</div>Agliohttps://wiki.postgresql.org/index.php?title=HowToTranslate&diff=28234HowToTranslate2016-09-16T17:38:52Z<p>Aglio: /* Translation Source Management */</p>
<hr />
<div>= How to Translate Releases =<br />
<br />
This is a set of instructions for Regional Contacts (RCs) and Advocacy volunteers on how to translate major version releases and other PR materials for PostgreSQL. It is not about translating the web site or translating PostgreSQL itself.<br />
<br />
== General Information ==<br />
<br />
=== Procedure & Timeline (skip for 9.6) ===<br />
<br />
For PostgreSQL 9.6, there will be no timeline countdown. The instructions below are for a release with a normal planning window. If you are working on translating 9.6, please skip ahead to the next section.<br />
<br />
Generally you will have a very short time to get a release translated. The schedule generally goes like this:<br />
<br />
# Day Minus 15: draft release send to Regional Contacts for questions and typo-spotting.<br />
# Day Minus 12: release finalized, offered to RCs for translation<br />
# Day Minus 6: draft copies of all languages checked in<br />
# Day Minus 4: final versions of all languages checked in <br />
<br />
Yes, that does mean that you need to have your translations finalized at least 4 days before the final release (and preferably earlier). This is because all Presskits need to be integrated into the www.postgresql.org infrastructure, checked, and corrected.<br />
<br />
The translation cycle generally goes like this:<br />
<br />
# Do draft translation<br />
# Send it to your proofreader for corrections<br />
# Correct mistakes<br />
# Send it back to proofreader for check<br />
# Send it in to Josh / check in to Git for HTML checking<br />
# Correct HTML errors<br />
# Finalize<br />
<br />
=== Encoding ===<br />
<br />
All translations of HTML documents must be UTF8 and not any other encoding. Our web infrastructure is UTF8 only.<br />
<br />
=== ProofReading ===<br />
<br />
All translations must be checked by someone ''other than the person who did the translation'' to look for mistakes in spelling, punctuation and grammar. It is not humanly possible to proofread your own work. Note that this proofreader does not need to be a PostgreSQL community member; they can just be a friend of yours who writes your language very well.<br />
<br />
Stupid grammar and spelling mistakes reflect badly on the whole project and make us look amateur. Don't let them get out.<br />
<br />
For the groups where several RCs have the same language, of course, the RCs can check each other's work.<br />
<br />
=== Sharing Translation Work ===<br />
<br />
RCs are strongly encouraged to share work on the translations with other community members, especially other RCs. Several languages, notably Spanish and German, have several RCs who share responsibility for them. It is up to you to figure out how to divide up the work; however, you must coordinate with each other because there will be only ''one'' Spanish presskit.<br />
<br />
'''Warning: Do not, under any circumstances, post the contents of the press release to a public mailing list, forum, or blog while you are working on it!'''<br />
<br />
Using closed, private archive mailing lists (such as translators@postgresql.org) is fine, but lists like pgsql-es-ayuda would be a mess. Don't do it.<br />
<br />
== Files to Translate ==<br />
<br />
There are ''two'' files you need to translate for a major version release. If you do not translate ''both'' of them, you won't be included in the release process. While the two do share text, it is formatted differently in each file and needs to be translated as a separate file.<br />
<br />
=== release.translate.txt ===<br />
<br />
This file is the text of the e-mail for Regional Contacts to send out on the day of the release. It is pure text for that reason, and is relatively short.<br />
<br />
==== Customizations ====<br />
<br />
Each RC will be customizing this text with their own contact information, you will notice a block in the middle of the text file which looks like this:<br />
<br />
YOUR NAME HERE<br />
YOUR @POSTGRESQL.ORG EMAIL HERE<br />
YOUR PHONE NUMBER HERE<br />
YOUR LOCALIZED WEB SITE HERE, IF ANY<br />
<br />
You needn't translate this block, as it will be filled in by the RC when they send the e-mail (hopefully!). Also there is a dateline at the beginning of the release, like this:<br />
<br />
DATE HERE: The PostgreSQL Global Development Group has released ...<br />
<br />
You will need to replace the "DATE HERE" words with the translated final date when the final release date is confirmed, about 5 days from the actual release.<br />
<br />
==== Git Users: Directories ====<br />
<br />
Git Users: Under press/releases/9.6/ there should be a directory with your two-letter or four-letter language code, e.g. "fr", "jp", "pt_BR". If there is not, then create one. All of the files you translate will go in there.<br />
<br />
==== Release File Name ====<br />
<br />
When you are finished translating, you should rename this file to "release.XX.txt" where "XX" is your countries's ISO code. e.g. "release.br.txt" or "release.usa.txt".<br />
<br />
=== presskit96.html ===<br />
<br />
This file becomes the online Press Kit for the release. It includes the text of the e-mail release, as well as a collection of links, expanded quotes, and further information about PostgreSQL. <br />
<br />
The difficulty with this file is that it's full of HTML markup which has been checked extensively by our web staff. As such, it's critically important that you translate the text ''without'' modifying any of the HTML tags at all, except for the Customization section below.<br />
<br />
Save this file as "presskit96.html" in you country code directory (or just email it to Josh). That is, do not change the name; just change the directory.<br />
<br />
Note: a couple of the links say "(English)". This is to indicate that the documents linked to will not be translated, and should contain a warning that the link goes to an English-language document.<br />
<br />
en/presskit96.html is supplied as an example for you to look at.<br />
<br />
==== Customizations ====<br />
<br />
In the center of the page is the Contact section. You need to customize this section. First, you need to add links to your language/region's PostgreSQL community page:<br />
<br />
<pre><p>Web Pages</p><br />
<ul><br />
<li><a href="http://www.postgresql.org">PostgreSQL home page</a></li><br />
<li><a href="YOUR LOCALIZED POSTGRES PAGE">NAME OF YOUR LOCALIZED POSTGRES PAGE</a></li><br />
</ul></pre><br />
<br />
That second link needs to be customized to your local Postgres community page, like so:<br />
<br />
<pre><li><a href="http://www.postgresql.org.br/">Comunidade Brasileira de PostgreSQL</a></li></pre><br />
<br />
If you are translating for a language which has multiple local websites (Spanish, German, Italian, etc.) then please add additional Listitems with the additional pages. If you do not have a localized web site, simply delete that line.<br />
<br />
The second customization you need to make is here:<br />
<br />
<pre><p>Press Inquiries</p><br />
<p>REGIONAL CONTACT NAME HERE<br /><br />
<a href="RC@POSTGRESQL.ORG">REGIONAL CONTACT EMAIL HERE</a><br /><br />
REGIONAL CONTACT PHONE HERE</p></pre><br />
<br />
This is where you put other contact information for the regional contacts in your language. For example:<br />
<br />
<pre><p>Guido Barosio<br /><br />
<a href="ar@postgresql.org">ar@postgresql.org</a><br /><br />
Cell: +54911-6641-1945</p></pre><br />
<br />
If your language covers multiple Regional Contacts, then list them all, one after the other, in the above format, ordered alphabetically by region name. Example:<br />
<br />
<pre><p>Argentina<br /><br />
Guido Barosio<br /><br />
<a href="ar@postgresql.org">ar@postgresql.org</a><br /><br />
Cell: +54911-6641-1945</p><br />
<p>Chile<br /><br />
Álvaro Herrera<br /><br />
<a href="alvherre@postgresql.org">alvherre@postgresql.org</a><br /><br />
Phone: +56-9-74990919</p><br />
<br />
etc.<br />
</pre><br />
<br />
See the English version of the release for a good example of multiple contacts.<br />
<br />
== Translation Source Management ==<br />
<br />
There are two ways to share and collaborate on editing translations: e-mail and git. If you are part of a translation "team" (e.g. Spanish) then you will need to pick ''one'' of these ways to use. Git is preferred for those who know how to use it, but e-mail is available if needed.<br />
<br />
=== Translating by git ===<br />
<br />
The releases are also available from git.postgresql.org. Git is strongly recommended for translation teams (Spanish, German, etc.) in order to coordinate their activities. However, Git syntax and concepts are not intuitive, so you may not want to use it if you don't have prior experience.<br />
<br />
In order to be able to commit your stuff from git, please follow this procedure:<br />
<br />
# get a PostgreSQL Community Profile, if you don't have one already.<br />
# add your ssh key to your Profile.<br />
# e-mail Josh about being added to the git repo<br />
# clone the git repo:<br />
<br />
git clone ssh://git@git.postgresql.org/press.git<br />
<br />
5. add your translation files, and then add them to git<br />
<br />
mkdir releases/9.6/XX<br />
... create the initial version of the files ...<br />
git add releases/9.6/XX<br />
git commit -a # make sure you only include the interesting files!<br />
<br />
7. push a copy to the central repository<br />
<br />
git commit -a<br />
git push origin<br />
<br />
If you are working with others, you will need to frequently "pull" a copy of your translations before doing work yourself:<br />
<br />
git pull origin<br />
<br />
When you are done with your translations, notify us using the translators@ list and we'll merge the branches.<br />
<br />
Please also read [[Working With Git]]<br />
<br />
<br />
=== Translating by E-mail ===<br />
<br />
Josh will send the Regional Contacts list the final copies of the translate files in an e-mailed zip archive, and later on any line-item edits you need to have if we have last-minute text fixes. <br />
<br />
You then e-mail around copies of the files to your co-translators and proofreader(s), being careful to make sure each person has the most updated version. I suggest using version numbers to ensure this.<br />
<br />
Then you rename the files appropriately, zip them (or bzip or gzip) into an archive, and e-mail them to Josh. The zipping of the files is important because it prevents e-mail clients and servers from mangling the encodings, which otherwise tends to happen.<br />
<br />
[[Category:Advocacy]]</div>Aglio