Don't wait for the commit record to be replicated if we wrote no WAL. When using synchronous replication, we waited for the commit record to be replicated, but if we our transaction didn't write any other WAL records, that's not required because we don't even flush the WAL locally to disk in that case. This lead to long waits when committing a transaction that only modified a temporary table. Bug spotted by Thom Brown.
http://git.postgresql.org/pg/commitdiff/fe546f3da6a5ff1d879f587728f74ec457f0ee5f

Andrew Dunstan a poussé :

Don't override arguments set via options with positional arguments. A number of utility programs were rather careless about paremeters that can be set via both an option argument and a positional argument. This leads to results which can violate the Principal Of Least Astonishment. These changes refuse to use positional arguments to override settings that have been made via positional arguments. The changes are backpatched to all live branches.
http://git.postgresql.org/pg/commitdiff/1b37a8c3cc4f0615f80d6007e2bbd47c6bd7e1e3

After PageSetAllVisible, use MarkBufferDirty. Previously, we used SetBufferCommitInfoNeedsSave, but that's really intended for dirty-marks we can theoretically afford to lose, such as hint bits. As for 9.2, the PD_ALL_VISIBLE mustn't be lost in this way, since we could then end up with a heap page that isn't all-visible and a visibility map page that is all visible, causing index-only scans to return wrong answers.
http://git.postgresql.org/pg/commitdiff/e93c0b820f03e96ae0549cd30805ae734e5d5e2f

Revise parameterized-path mechanism to fix assorted issues. This patch adjusts the treatment of parameterized paths so that all paths with the same parameterization (same set of required outer rels) for the same relation will have the same rowcount estimate. We cache the rowcount estimates to ensure that property, and hopefully save a few cycles too. Doing this makes it practical for add_path_precheck to operate without a rowcount estimate: it need only assume that paths with different parameterizations never dominate each other, which is close enough to true anyway for coarse filtering, because normally a more-parameterized path should yield fewer rows thanks to having more join clauses to apply. In add_path, we do the full nine yards of comparing rowcount estimates along with everything else, so that we can discard parameterized paths that don't actually have an advantage. This fixes some issues I'd found with add_path rejecting parameterized paths on the grounds that they were more expensive than not-parameterized ones, even though they yielded many fewer rows and hence would be cheaper once subsequent joining was considered. To make the same-rowcounts assumption valid, we have to require that any parameterized path enforce *all* join clauses that could be obtained from the particular set of outer rels, even if not all of them are useful for indexing. This is required at both base scans and joins. It's a good thing anyway since the net impact is that join quals are checked at the lowest practical level in the join tree. Hence, discard the original rather ad-hoc mechanism for choosing parameterization joinquals, and build a better one that has a more principled rule for when clauses can be moved. The original rule was actually buggy anyway for lack of knowledge about which relations are part of an outer join's outer side; getting this right requires adding an outer_relids field to RestrictInfo.
http://git.postgresql.org/pg/commitdiff/5b7b5518d0ea56c422a197875f7efa5deddbb388

Adjust join_search_one_level's handling of clauseless joins. For an initial relation that lacks any join clauses (that is, it has to be cartesian-product-joined to the rest of the query), we considered only cartesian joins with initial rels appearing later in the initial-relations list. This creates an undesirable dependency on FROM-list order. We would never fail to find a plan, but perhaps we might not find the best available plan. Noted while discussing the logic with Amit Kapila. Improve the comments a bit in this area, too. Arguably this is a bug fix, but given the lack of complaints from the field I'll refrain from back-patching.
http://git.postgresql.org/pg/commitdiff/1f0363001166ef6a43619846e44cfb9dbe7335ed

Use fuzzy not exact cost comparison for the final tie-breaker in add_path. Instead of an exact cost comparison, use a fuzzy comparison with 1e-10 delta after all other path metrics have proved equal. This is to avoid having platform-specific roundoff behaviors determine the choice when two paths are really the same to our cost estimators. Adjust the recently-added test case that made it obvious we had a problem here.
http://git.postgresql.org/pg/commitdiff/33e99153e93b9accfa51ac036828144e1c2507b7

Alvaro Herrera a poussé :

Recast "ONLY" column CHECK constraints as NO INHERIT. The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd28dbec65a6b144e0cd3d0bfe25913c3ac, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke. Some tweaks by me
http://git.postgresql.org/pg/commitdiff/09ff76fcdb275769ac4d1a45a67416735613d04b

Correctifs rejetés (à ce jour)

Pas de déception cette semaine :-)

Correctifs en attente

Heikki Linnakangas sent in a patch to fix some infelicities in localized error context messages.

Etsuro Fujita sent in another revision of the patch to validate file_fdw tables for not-NULL constraints.

Kyotaro HORIGUCHI sent in three revisions of a fix for a bug where the checkpointer on hot standbys runs without looking checkpoint_segments. Fujii Masao sent in another fixing an infelicity in the last.

Noah Misch sent in a patch to fix an issue where {ts,array}_typanalyze consumed much more memory than needed.

Jameison Martin sent in a patch to optimize the case of tables with large numbers of columns, truncating the NULL bitmap at the last non-NULL column.

Alexander Shulgin sent in two more revisions of a patch to add libpq URIs to the regression tests.

Alvaro Herrera sent in a patch to add ALTER EXTENSION ... OWNED.

Robert Haas sent in a patch to fix a bug in lazy_scan_heap() that could cause index-only scans to give wrong results.

Laurenz Albe sent in a patch to fix a place where foreign table scan estimates were frozen at 1000 rows, independent of statistics gathered on same.

Noah Misch sent in a patch to fix an issue in B-tree page deletion.

Jan Urbanski sent in a patch to fix an issue with PL/PythonU triggers on composite-type columns. columns