Les mises à jour de sécurité 10.2, 9.6.7, 9.5.11, 9.4.16, 9.3.21, et 9.2.25 ont été publiées. Merci de lire l'annonce ci-dessous et d'appliquer la mise à jour lors du prochain créneau d'indisponibilité : https://www.postgresql.org/about/news/1829/

Le PGDay suisse 2018 aura lieu à Rapperswil-Jona (près de Zurich) le 29 juin 2018. L'appel à conférenciers court du 6 février au 14 avril 2018, et les inscriptions sont ouvertes du 6 février au 28 juin 2018 : http://www.pgday.ch/2018/

Les nouveautés des produits dérivés

• pgwatch2 1.3.0, un outil de surveillance pour PostgreSQL : https://github.com/cybertec-postgresql/pgwatch2/
• TablePlus, un outil moderne, nativement mac, pour les bases de données relationnelles avec compatibilité PostgreSQL : https://tableplus.io/
• psycopg2 2.7.4, un connecteur python pour PostgreSQL : http://initd.org/psycopg/articles/2018/02/08/psycopg-274-released/

Offres d'emplois autour de PostgreSQL en février

• Internationales : http://archives.postgresql.org/pgsql-jobs/2018-02/
• Francophones : http://forums.postgresql.fr/viewforum.php?id=4

PostgreSQL Local

• Prague PostgreSQL Developer Day 2018 (P2D2 2018) est une série de conférences sur deux jours qui aura lieu les 14 & 15 février 2018 à Prague (République Tchèque) : http://www.p2d2.cz/
• [ndt: MeetUp à Paris le 22 février : https://www.meetup.com/fr-FR/PostgreSQL-User-Group-Paris/]
• La PGConf India 2018 aura lieu les 22 & 23 février 2018 à Bengalore (État du Karnataka en Inde) : http://pgconf.in/
• [ndt: MeetUp à Lyon le 28 février : https://www.meetup.com/fr-FR/PostgreSQL-Lyon-User-Group/]
• [ndt: MeetUp à Nantes le 28 février : https://www.meetup.com/fr-FR/PostgreSQL-User-Group-Nantes/]
• PostgreSQL@SCaLE est un événement de 2 jours à double programmes qui aura lieu les 8 & 9 mars 2018 au centre de convention de Pasadena, intégré au SCaLE 16X : http://www.socallinuxexpo.org/scale/16x/cfp
• Le PGDay nordique 2018 se tiendra à Oslo (Norvège) à l'hôtel Radisson Blu le 13 mars 2018. Les inscriptions sont ouvertes et le programme a été publié : https://2018.nordicpgday.org/
• Le pgDay Paris 2018 aura lieu à l'espace Saint Martin (Paris, France) le 15 mars 2018. Les inscriptions sont ouvertes : http://2018.pgday.paris/callforpapers/
• PGConf APAC 2018 se tiendra à Singapour du 22 au 24 mars 2018 : http://2018.pgconfapac.org/
• La conférence germanophone PostgreSQL Conference 2018 aura lieu le 13 avril 2018 à Berlin : http://2018.pgconf.de/
• La PGConfNepal 2018 se tiendra les 4 & 5 mai 2018 à l'université de Katmandou, Dulikhel, Népal. L'appel à conférenciers court jusqu'au 15 février 2018 : https://postgresconf.org/conferences/Nepal2018/program/proposals https://postgresconf.org/conferences/Nepal2018
• La PGCon 2018 se tiendra à Ottawa du 29 mai au 1er juin 2018 : https://www.pgcon.org/2018/
• La PGConf.Brazil 2018 aura lieu à São Paulo (Brésil) les 3 & 4 août 2018. L'appel à conférenciers court jusqu'au 28 février 2018 : ã

PostgreSQL dans les média

• Planet PostgreSQL : http://planet.postgresql.org/
• Planet PostgreSQLFr : http://planete.postgresql.fr/

PostgreSQL Weekly News / les nouvelles hebdomadaires vous sont offertes cette semaine par David Fetter. Traduction par l'équipe PostgreSQLFr sous licence CC BY-NC-SA. La version originale se trouve à l'adresse suivante : http://www.postgresql.org/message-id/20180211195912.GA14885@fetter.org

Proposez vos articles ou annonces avant dimanche 15:00 (heure du Pacifique). Merci de les envoyer en anglais à david (a) fetter.org, en allemand à pwn (a) pgug.de, en italien à pwn (a) itpug.org et en espagnol à pwn (a) arpug.com.ar.

Correctifs appliqués

Peter Eisentraut pushed:

• doc: Update mentions of MD5 in the documentation. Reported-by: Shay Rojansky <roji@roji.org> https://git.postgresql.org/pg/commitdiff/ad14919ac901e9703d81a5bf8a6b608719c85b60
• Add more information_schema columns - table_constraints.enforced - triggers.action_order - triggers.action_reference_old_table - triggers.action_reference_new_table. Reviewed-by: Michael Paquier <michael.paquier@gmail.com> https://git.postgresql.org/pg/commitdiff/32ff2691173559e5f0ca3ea9cd5db134af6ee37d
• Make new triggers tests more robust. Add explicit collation on the trigger name to avoid locale dependencies. Also restrict the tables selected, to avoid interference from concurrently running tests. https://git.postgresql.org/pg/commitdiff/7c44b75a2a0705bf17d0e7ef02b1a0a769306fa5
• Refine SSL tests test name reporting. Instead of using the psql/libpq connection string as the displayed test name and relying on "notes" and source code comments to explain the tests, give the tests self-explanatory names, like we do elsewhere. Reviewed-by: Michael Paquier <michael.paquier@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> https://git.postgresql.org/pg/commitdiff/b3a101eff0fd3747bebf547b1769e28f820f4515

Tom Lane pushed:

• Skip setting up shared instrumentation for Hash node if not needed. We don't need to set up the shared space for hash join instrumentation data if instrumentation hasn't been requested. Let's follow the example of the similar Sort node code and save a few cycles by skipping that when we can. This reverts commit d59ff4ab3 and instead allows us to use the safer choice of passing noError = false to shm_toc_lookup in ExecHashInitializeWorker, since if we reach that call there should be a TOC entry to be found. Thomas Munro Discussion: https://postgr.es/m/E1ehkoZ-0005uW-43%40gemulon.postgresql.org https://git.postgresql.org/pg/commitdiff/05d0f13f0701d84e4e6784da336aabcc2dfc8ade
• Ensure that all temp files made during pg_upgrade are non-world-readable. pg_upgrade has always attempted to ensure that the transient dump files it creates are inaccessible except to the owner. However, refactoring in commit 76a7650c4 broke that for the file containing "pg_dumpall -g" output; since then, that file was protected according to the process's default umask. Since that file may contain role passwords (hopefully encrypted, but passwords nonetheless), this is a particularly unfortunate oversight. Prudent users of pg_upgrade on multiuser systems would probably run it under a umask tight enough that the issue is moot, but perhaps some users are depending only on pg_upgrade's umask changes to protect their data. To fix this in a future-proof way, let's just tighten the umask at process start. There are no files pg_upgrade needs to write at a weaker security level; and if there were, transiently relaxing the umask around where they're created would be a safer approach. Report and patch by Tom Lane; the idea for the fix is due to Noah Misch. Back-patch to all supported branches. Security: CVE-2018-1053 https://git.postgresql.org/pg/commitdiff/a926eb84e07a604da6d059eca1fd87f919bb5d7a
• Doc: move info for btree opclass implementors into main documentation. Up to now, useful info for writing a new btree opclass has been buried in the backend's nbtree/README file. Let's move it into the SGML docs, in preparation for extending it with info about "in_range" functions in the upcoming window RANGE patch. To do this, I chose to create a new chapter for btree indexes in Part VII (Internals), parallel to the chapters that exist for the newer index AMs. This is a pretty short chapter as-is. At some point somebody might care to flesh it out with more detail about btree internals, but that is beyond the scope of my ambition for today. Discussion: https://postgr.es/m/23141.1517874668@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/3785f7eee3d98bc0a7ac2576aac9c0be974217d4
• Support all SQL:2011 options for window frame clauses. This patch adds the ability to use "RANGE offset PRECEDING/FOLLOWING" frame boundaries in window functions. We'd punted on that back in the original patch to add window functions, because it was not clear how to do it in a reasonably data-type-extensible fashion. That problem is resolved here by adding the ability for btree operator classes to provide an "in_range" support function that defines how to add or subtract the RANGE offset value. Factoring it this way also allows the operator class to avoid overflow problems near the ends of the datatype's range, if it wishes to expend effort on that. (In the committed patch, the integer opclasses handle that issue, but it did not seem worth the trouble to avoid overflow failures for datetime types.) The patch includes in_range support for the integer_ops opfamily (int2/int4/int8) as well as the standard datetime types. Support for other numeric types has been requested, but that seems like suitable material for a follow-on patch. In addition, the patch adds GROUPS mode which counts the offset in ORDER-BY peer groups rather than rows, and it adds the frame_exclusion options specified by SQL:2011. As far as I can see, we are now fully up to spec on window framing options. Existing behaviors remain unchanged, except that I changed the errcode for a couple of existing error reports to meet the SQL spec's expectation that negative "offset" values should be reported as SQLSTATE 22013. Internally and in relevant parts of the documentation, we now consistently use the terminology "offset PRECEDING/FOLLOWING" rather than "value PRECEDING/FOLLOWING", since the term "value" is confusingly vague. Oliver Ford, reviewed and whacked around some by me Discussion: https://postgr.es/m/CAGMVOdu9sivPAxbNN0X+q19Sfv9edEPv=HibOJhB14TJv_RCQg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/0a459cec96d3856f476c2db298c6b52f592894e8
• Fix RelationBuildPartitionKey's processing of partition key expressions. Failure to advance the list pointer while reading partition expressions from a list results in invoking an input function with inappropriate data, possibly leading to crashes or, with carefully crafted input, disclosure of arbitrary backend memory. Bug discovered independently by Álvaro Herrera and David Rowley. This patch is by Álvaro but owes something to David's proposed fix. Back-patch to v10 where the issue was introduced. Security: CVE-2018-1052 https://git.postgresql.org/pg/commitdiff/3492a0af0bd37e7f23e27fd3f5537f414ee9ab9b
• Last-minute updates for release notes. Security: CVE-2018-1052, CVE-2018-1053 https://git.postgresql.org/pg/commitdiff/1eb5d43beed9d8cdc61377867f0a53eb2cfba0c4
• Fix oversight in CALL argument handling, and do some minor cleanup. CALL statements cannot support sub-SELECTs in the arguments of the called procedure, since they just use ExecEvalExpr to evaluate such arguments. Teach transformSubLink() to reject the case, as it already does for other contexts in which subqueries are not supported. In passing, s/EXPR_KIND_CALL/EXPR_KIND_CALL_ARGUMENT/ to make that enum symbol line up more closely with the phrasing of the error messages it is associated with. And fix someone's weak grasp of English grammar in the preceding EXPR_KIND_PARTITION_EXPRESSION addition. Also update an incorrect comment in resolve_unique_index_expr (possibly it was correct when written, but nowadays transformExpr definitely does reject SRFs here). Per report from Pavel Stehule --- but this resolves only one of the bugs he mentions. Discussion: https://postgr.es/m/CAFj8pRDxOwPPzpA8i+AQeDQFj7bhVw-dR2==rfWZ3zMGkm568Q@mail.gmail.com https://git.postgresql.org/pg/commitdiff/65b1d767856d96c7d6f952f30890dd5b7d4b66bb
• Avoid premature free of pass-by-reference CALL arguments. Prematurely freeing the EState used to evaluate CALL arguments led, in some cases, to passing dangling pointers to the procedure. This was masked in trivial cases because the argument pointers would point to Const nodes in the original expression tree, and in some other cases because the result value would end up in the standalone ExprContext rather than in memory belonging to the EState --- but that wasn't exactly high quality programming either, because the standalone ExprContext was never explicitly freed, breaking assorted API contracts. In addition, using a separate EState for each argument was just silly. So let's use just one EState, and one ExprContext, and make the latter belong to the former rather than be standalone, and clean up the EState (and hence the ExprContext) post-call. While at it, improve the function's commentary a bit. Discussion: https://postgr.es/m/29173.1518282748@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/d02d4a6d4f27c223f48b03a5e651a22c8460b3c4
• Fix assorted errors in pg_dump's handling of extended statistics objects. pg_dump supposed that a stats object necessarily shares the same schema as its underlying table, and that it doesn't have a separate owner. These things may have been true during early development of the feature, but they are not true as of v10 release. Failure to track the object's schema separately turns out to have only limited consequences, because pg_get_statisticsobjdef() always schema- qualifies the target object name in the generated CREATE STATISTICS command (a decision out of step with the rest of ruleutils.c, but I digress). Therefore the restored object would be in the right schema, so that the only problem is that the TOC entry would be mislabeled as to schema. That could lead to wrong decisions for schema-selective restores, for example. The ownership issue is a bit more serious: not only was the TOC entry potentially mislabeled as to owner, but pg_dump didn't bother to issue an ALTER OWNER command at all, so that after restore the stats object would continue to be owned by the restoring superuser. A final point is that decisions as to whether to dump a stats object or not were driven by whether the underlying table was dumped or not. While that's not wrong on its face, it won't scale nicely to the planned future extension to cross-table statistics. Moreover, that design decision comes out of the view of stats objects as being auxiliary to a particular table, like a rule or trigger, which is exactly where the above problems came from. Since we're now treating stats objects more like independent objects in their own right, they ought to behave like standalone objects for this purpose too. So change to using the generic selectDumpableObject() logic for them (which presently amounts to "dump if containing schema is to be dumped"). Along the way to fixing this, restructure so that getExtendedStatistics collects the identity info (only) for all extended stats objects in one query, and then for each object actually being dumped, we retrieve the definition in dumpStatisticsExt. This is necessary to ensure that schema-qualification in the generated CREATE STATISTICS command happens with respect to the search path that pg_dump will now be using at restore time (ie, the schema the stats object is in, not that of the underlying table). It's probably also significantly faster in the typical scenario where only a minority of tables have extended stats. Back-patch to v10 where extended stats were introduced. Discussion: https://postgr.es/m/18272.1518328606@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5c9f2564fabbc770ead3bd92136fdafc43654f27

Robert Haas pushed:

• Fix possible crash in partition-wise join. The previous code assumed that we'd always succeed in creating child-joins for a joinrel for which partition-wise join was considered, but that's not guaranteed, at least in the case where dummy rels are involved. Ashutosh Bapat, with some wordsmithing by me. Discussion: http://postgr.es/m/CAFjFpRf8=uyMYYfeTBjWDMs1tR5t--FgOe2vKZPULxxdYQ4RNw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f069c91a5793ff6b7884120de748b2005ee7756f
• Avoid valgrind complaint about write() of uninitalized bytes. LogicalTapeFreeze() may write out its first block when it is dirty but not full, and then immediately read the first block back in from its BufFile as a BLCKSZ-width block. This can only occur in rare cases where very few tuples were written out, which is currently only possible with parallel external tuplesorts. To avoid valgrind complaints, tell it to treat the tail of logtape.c's buffer as defined. Commit 9da0cc35284bdbe8d442d732963303ff0e0a40bc exposed this problem but did not create it. LogicalTapeFreeze() has always tended to write out some amount of garbage bytes, but previously never wrote less than one block of data in total, so the problem was masked. Per buildfarm members lousyjack and skink. Peter Geoghegan, based on a suggestion from Tom Lane and me. Some comment revisions by me. https://git.postgresql.org/pg/commitdiff/9fafa413ac602624e10f61ef44a20c17029d43d8
• Fix incorrect grammar. Etsuro Fujita Discussion: http://postgr.es/m/5A7981EA.8020201@lab.ntt.co.jp https://git.postgresql.org/pg/commitdiff/23209457314f6fd89fcd251a8173b0129aaa95a2
• Remove prototype for fmgr() function, which no longer exists. Commit 5ded4bd21403e143dd3eb66b92d52732fdac1945 removed the code for this function, but neglected to remove the prototype and associated comments. Dagfinn Ilmari Mannsåker Discussion: http://postgr.es/m/d8j4lmuxjzk.fsf@dalvik.ping.uio.no https://git.postgresql.org/pg/commitdiff/4815dfa10f4db8835b7424da22a4011b53040606
• Update out-of-date comment in StartupXLOG. Commit 4b0d28de06b28e57c540fca458e4853854fbeaf8 should have updated this comment, but did not. Thomas Munro Discussion: http://postgr.es/m/CAEepm=0iJ8aqQcF9ij2KerAkuHF3SwrVTzjMdm1H4w++nfBf9A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b98a7cd58f6189833e6ad6ac7e7ad5b6412409fd
• postgres_fdw: Push down UPDATE/DELETE joins to remote servers. Commit 0bf3ae88af330496517722e391e7c975e6bad219 allowed direct foreign table modification; instead of fetching each row, updating it locally, and then pushing the modification back to the remote side, we would instead do all the work on the remote server via a single remote UPDATE or DELETE command. However, that commit only enabled this optimization when join tree consisted only of the target table. This change allows the same optimization when an UPDATE statement has a FROM clause or a DELETE statement has a USING clause. This works much like ordinary foreign join pushdown, in that the tables must be on the same remote server, relevant parts of the query must be pushdown-safe, and so forth. Etsuro Fujita, reviewed by Ashutosh Bapat, Rushabh Lathia, and me. Some formatting corrections by me. Discussion: http://postgr.es/m/5A57193A.2080003@lab.ntt.co.jp Discussion: http://postgr.es/m/b9cee735-62f8-6c07-7528-6364ce9347d0@lab.ntt.co.jp https://git.postgresql.org/pg/commitdiff/1bc0100d270e5bcc980a0629b8726a32a497e788
• postgres_fdw: Remove CTID output from some tests. Commit 1bc0100d270e5bcc980a0629b8726a32a497e788 added these tests, but they're not stable enough to survive in the buildfarm. Remove CTIDs from the output in the hopes of fixing that. https://git.postgresql.org/pg/commitdiff/882ea509fe7a4711fe25463427a33262b873dfa1
• Fix possible infinite loop with Parallel Append. When the previously-chosen plan was non-partial, all pa_finished flags for partial plans are now set, and pa_next_plan has not yet been set to INVALID_SUBPLAN_INDEX, the previous code could go into an infinite loop. Report by Rajkumar Raghuwanshi. Patch by Amit Khandekar and me. Review by Kyotaro Horiguchi. Discussion: http://postgr.es/m/CAJ3gD9cf43z78qY=U=H0HvOEN341qfRO-vLpnKPSviHeWgJQ5w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/88fdc7006018b92d6ec92c54b3819764703daaba
• Avoid listing the same ResultRelInfo in more than one EState list. Doing so causes EXPLAIN ANALYZE to show trigger statistics multiple times. Commit 2f178441044be430f6b4d626e4dae68a9a6f6cec seems to be to blame for this. Amit Langote, revieed by Amit Khandekar, Etsuro Fujita, and me. https://git.postgresql.org/pg/commitdiff/e44dd84325c277fd031b9ef486c51a0946c7d3a0
• Fix incorrect method name in comment. Atsushi Torikoshi Discussion: http://postgr.es/m/1b056262-4bc0-a982-c899-bb67a0a7fd52@lab.ntt.co.jp https://git.postgresql.org/pg/commitdiff/b78d0160da13109c69acfd0caded3f920bff2f3b
• postgres_fdw: Attmempt to stabilize regression tests. Even after commit 882ea509fe7a4711fe25463427a33262b873dfa1, some buildfarm members are still failing in the postgres_fdw tests. Try to fix that by disabling use of remote statistics for some test cases. Etsuro Fujita Discussion: http://postgr.es/m/5A7D76CF.8080601@lab.ntt.co.jp https://git.postgresql.org/pg/commitdiff/958e20e42d6c346ab89f6c72e4262230161d1663
• Clear stmt_timeout_active if we disable_all_timeouts. Otherwise, we can end up with the flag set when the timeout is actually disabled, leading to misbehavior. Commit f8e5f156b30efee5d0038b03e38735773abcb7ed introduced this bug. Reported by Peter Eisentraut. Analysis and fix by Thomas Munro, tweaked by me. Discussion: http://postgr.es/m/6a909374-2602-7136-8c70-397330a418f3@2ndquadrant.com https://git.postgresql.org/pg/commitdiff/be42015fcc7f91574775a53df9923a36fabddc60
• Mark assorted GUC variables as PGDLLIMPORT. This makes life easier for extension authors. Metin Doslu Discussion: http://postgr.es/m/CAL1dPcfa45o1dC-c4t-48v0OZE6oy4ChJhObrtkK8mzNfXqDTA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/935dee9ad5a8d12f4d3b772a6e6c99d245e5ad44

Magnus Hagander pushed:

• Change default git repo URL to https. Since we now support the server side handler for git over https (so we're no longer using the "dumb protocol"), make https the primary choice for cloning the repository, and the git protocol the secondary choice. In passing, also change the links to git-scm.com from http to https. Reviewed by Stefan Kaltenbrunner and David G. Johnston https://git.postgresql.org/pg/commitdiff/9e039015501ad4033c093dee8dfc8b414634e953

Álvaro Herrera pushed:

• Mention partitioned indexes in "Data Definition" chapter. We can now create indexes more easily than before, so update this chapter to use the simpler instructions. After an idea of Amit Langote. I (Álvaro) opted to do more invasive surgery and remove the previous suggestion to create per-partition indexes, which his patch left in place. Discussion: https://postgr.es/m/eafaaeb1-f0fd-d010-dd45-07db0300f645@lab.ntt.co.jp Author: Amit Langote, Álvaro Herrera https://git.postgresql.org/pg/commitdiff/fad15f4a547ad433a28c370bd071b08df9e65f10

Correctifs en attente

Mark Rofail sent in two more revisions of a patch to implement foreign key arrays.

Takayuki Tsunakawa sent in another revision of a patch to fix an ECPG bug where freeing memory for pgtypes crashes on Windows.

Michaël Paquier sent in a patch to use base backup exclusion filters to reduce data transferred with pg_rewind.

Michaël Paquier sent in a patch to fix a typo in a comment in pg_multixact/offset in multixact.c.

Kyotaro HORIGUCHI sent in another revision of a patch to allow booleans to be partition bounds.

Tomas Vondra sent in another revision of a patch to implement BRIN multi-range indexes.

Takayuki Tsunakawa sent in a patch to reset temp schema on connect.

Amit Langote sent in two more revisions of a patch to refactor the partition tuple conversion maps handling code and initialize per-partition objects lazily during tuple-routing.

Pierre Ducroquet sent in another revision of a patch atop the JIT patch to support LLVM 9.1.

Ildus Kurbangaliev sent in another revision of a patch to implement custom compression methods.

Nikhil Sontakke sent in another revision of a patch to fix some faulty Logical Decoding and HeapTupleSatisfiesVacuum assumptions.

Thomas Munro sent in another revision of a patch to fix a comment in src/backend/access/transam/xlog.c.

Peter Geoghegan sent in a patch to mark logtape.c buffer's tail as defined to Valgrind.

Claudio Freire sent in four more revisions of a patch to enable VACUUM to use more than 1GB of work mem.

Nikhil Sontakke sent in another revision of a patch to implement logical decoding of two-phase transactions.

Pavel Stěhule sent in another revision of a patch to implement schema variables.

Artur Zakirov sent in another revision of a patch to implement shared Ispell dictionaries.

Nathan Bossart sent in a patch to allow users to change the WAL segment size of a cluster with pg_resetwal.

Peter Eisentraut sent in a patch to fix some confusing SSL test names.

Ashutosh Bapat sent in two more revisions of a patch to do better partition matching for partition-wise joins.

Pavan Deolasee sent in another revision of a patch to implement MERGE.

Pierre Ducroquet sent in another revision of a patch atop the JIT patch to support JIT compiling with LLVM v10.0.

Jeevan Chalke sent in another revision of a patch to implement partition-wise aggregation/grouping.

Ildus Kurbangaliev sent in a patch to add 'autovacuum_table_priority' to the current list of automatic vacuuming settings.

Peter Geoghegan sent in another revision of a patch to add a Bloom filter data structure implementation and use same to add amcheck verification of indexes against the heap.

Claudio Freire sent in another revision of a patch to vacuum the FSM more frequently.

Masahiko Sawada sent in another revision of a patch to keep track of writing on non-temporary relations, support atomic commits involving multiple foreign servers, and add postgres_fdw support for atomic distributed transaction commit.

Michaël Paquier sent in a patch to disable src/test/[ssl|ldap] when not building with SSL/LDAP support.

Kyotaro HORIGUCHI sent in a patch to let plan_create_index_workers honor_dsm_none.

Kyotaro HORIGUCHI sent in a patch to increase the minimum allowable value of max_connections from 10 to 20.

Konstantin Knizhnik sent in a patch for PL/pgsql which reports an error in the case of an empty attribute list for SELECT INTO.

Amit Langote sent in another revision of a patch to implement faster partition pruning.

Konstantin Knizhnik sent in another revision of a patch to implement a built-in connection pooler.

Peter Eisentraut sent in a patch to add ldapi support.

Andrew Dunstan sent in another revision of a patch to implement a faster ALTER TABLE ... ADD COLUMN ... DEFAULT ...

Etsuro Fujita sent in a patch to add some regression tests for the PostgreSQL FDW.

Andrey Borodin sent in a patch to enable using ICU as the default collation provider.

Thomas Munro sent in a patch to register and document LWTRANCHE_PARALLEL_HASH_JOIN.