La première Commitfest de la prochaine version de PostgreSQL va débuter sous peu. Époussetez vos patchs et aidez les autres à épousseter les leurs ! https://commitfest.postgresql.org/action/commitfest_view?id=18

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en juin

PostgreSQL Local

PostgreSQL dans les média

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.

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.

(lien vers l'article original)

Correctifs appliqués

Noah Misch a poussé :

Heikki Linnakangas a poussé :

Stephen Frost a poussé :

Tom Lane a poussé :

  • Add semicolons to eval'd strings to hide a minor Perl behavioral change. "eval q{foo}" used to complain that the error was on line 2 of the eval'd string, because eval internally tacked on "\n;" so that the end of the erroneous command was indeed on line 2. But as of Perl 5.18 it more sanely says that the error is on line 1. To avoid Perl-version-dependent regression test results, use "eval q{foo;}" instead in the two places where this matters. Per buildfarm. Since people might try to use newer Perl versions with older PG releases, back-patch as far as 9.0 where these test cases were added. http://git.postgresql.org/pg/commitdiff/035a5e1e8c346efe25df6be4627b5f24cc3736b1
  • Fix memory leak in LogStandbySnapshot(). The array allocated by GetRunningTransactionLocks() needs to be pfree'd when we're done with it. Otherwise we leak some memory during each checkpoint, if wal_level = hot_standby. This manifests as memory bloat in the checkpointer process, or in bgwriter in versions before we made the checkpointer separate. Reported and fixed by Naoya Anzai. Back-patch to 9.0 where the issue was introduced. In passing, improve comments for GetRunningTransactionLocks(), and add an Assert that we didn't overrun the palloc'd array. http://git.postgresql.org/pg/commitdiff/dbc6eb1f4b840d252031419d4bf694316812124f
  • Add ARM64 (aarch64) support to s_lock.h. Use the same gcc atomic functions as we do on newer ARM chips. (Basically this is a copy and paste of the __arm__ code block, but omitting the SWPB option since that definitely won't work.) Back-patch to 9.2. The patch would work further back, but we'd also need to update config.guess/config.sub in older branches to make them build out-of-the-box, and there hasn't been demand for it. Mark Salter http://git.postgresql.org/pg/commitdiff/5c7603c318872a42e1665b228f68fdf58714d945
  • Provide better message when CREATE EXTENSION can't find a target schema. The new message (and SQLSTATE) matches the corresponding error cases in namespace.c. This was thought to be a "can't happen" case when extension.c was written, so we didn't think hard about how to report it. But it definitely can happen in 9.2 and later, since we no longer require search_path to contain any valid schema names. It's probably also possible in 9.1 if search_path came from a noninteractive source. So, back-patch to all releases containing this code. Per report from Sean Chittenden, though this isn't exactly his patch. http://git.postgresql.org/pg/commitdiff/530acda4dabe26a4345eccd28a92dd23b1e7a94a
  • Put analyze_keyword back in explain_option_name production. In commit 2c92edad48796119c83d7dbe6c33425d1924626d, I broke "EXPLAIN (ANALYZE)" syntax, because I mistakenly thought that ANALYZE/ANALYSE were only partially reserved and thus would be included in NonReservedWord; but actually they're fully reserved so they still need to be called out here. A nicer solution would be to demote these words to type_func_name_keyword status (they can't be less than that because of "VACUUM [ANALYZE] ColId"). While that works fine so far as the core grammar is concerned, it breaks ECPG's grammar for reasons I don't have time to isolate at the moment. So do this for the time being. Per report from Kevin Grittner. Back-patch to 9.0, like the previous commit. http://git.postgresql.org/pg/commitdiff/3f783c882712db5a5e0056f271ff765edeb2571a
  • Prevent pushing down WHERE clauses into unsafe UNION/INTERSECT nests. The planner is aware that it mustn't push down upper-level quals into subqueries if the quals reference subquery output columns that contain set-returning functions or volatile functions, or are non-DISTINCT outputs of a DISTINCT ON subquery. However, it missed making this check when there were one or more levels of UNION or INTERSECT above the dangerous expression. This could lead to "set-valued function called in context that cannot accept a set" errors, as seen in bug #8213 from Eric Soroos, or to silently wrong answers in the other cases. To fix, refactor the checks so that we make the column-is-unsafe checks during subquery_is_pushdown_safe(), which already has to recursively inspect all arms of a set-operation tree. This makes qual_is_pushdown_safe() considerably simpler, at the cost that we will spend some cycles checking output columns that possibly aren't referenced in any upper qual. But the cases where this code gets executed at all are already nontrivial queries, so it's unlikely anybody will notice any slowdown of planning. This has been broken since commit 05f916e6add9726bf4ee046e4060c1b03c9961f2, which makes the bug over ten years old. A bit surprising nobody noticed it before now. http://git.postgresql.org/pg/commitdiff/964c0d0f80e485dd3a4073e073ddfd9bfdda90b2
  • Minor docs wordsmithing. Swap the order of a couple of phrases to clarify what the adjective "subsequent" applies to. Joshua Tolley http://git.postgresql.org/pg/commitdiff/7b1e893acd4b7637de93631781f82e0f6834b621
  • Remove fixed limit on the number of concurrent AllocateFile() requests. AllocateFile(), AllocateDir(), and some sister routines share a small array for remembering requests, so that the files can be closed on transaction failure. Previously that array had a fixed size, MAX_ALLOCATED_DESCS (32). While historically that had seemed sufficient, Steve Toutant pointed out that this meant you couldn't scan more than 32 file_fdw foreign tables in one query, because file_fdw depends on the COPY code which uses AllocateFile(). There are probably other cases, or will be in the future, where this nonconfigurable limit impedes users. We can't completely remove any such limit, at least not without a lot of work, since each such request requires a kernel file descriptor and most platforms limit the number we can have. (In principle we could "virtualize" these descriptors, as fd.c already does for the main VFD pool, but not without an additional layer of overhead and a lot of notational impact on the calling code.) But we can at least let the array size be configurable. Hence, change the code to allow up to max_safe_fds/2 allocated file requests. On modern platforms this should allow several hundred concurrent file_fdw scans, or more if one increases the value of max_files_per_process. To go much further than that, we'd need to do some more work on the data structure, since the current code for closing requests has potentially O(N^2) runtime; but it should still be all right for request counts in this range. Back-patch to 9.1 where contrib/file_fdw was introduced. http://git.postgresql.org/pg/commitdiff/007556bf08e6153c442fe3742adb3685fca3a0e0
  • Remove ALTER DEFAULT PRIVILEGES' requirement of schema CREATE permissions. Per discussion, this restriction isn't needed for any real security reason, and it seems to confuse people more often than it helps them. It could also result in some database states being unrestorable. So just drop it. Back-patch to 9.0, where ALTER DEFAULT PRIVILEGES was introduced. http://git.postgresql.org/pg/commitdiff/f3839ea117fba6fdb69c75a1fe145aa86a4c8ae3
  • Remove unnecessary restrictions about RowExprs in transformAExprIn(). When the existing code here was written, it made sense to special-case RowExprs because that was the only way that we could handle row comparisons at all. Now that we have record_eq() and arrays of composites, the generic logic for "scalar" types will in fact work on RowExprs too, so there's no reason to throw error for combinations of RowExprs and other ways of forming composite values, nor to ignore the possibility of using a ScalarArrayOpExpr. But keep using the old logic when comparing two RowExprs, for consistency with the main transformAExprOp() logic. (This allows some cases with not-quite-identical rowtypes to succeed, so we might get push-back if we removed it.) Per bug #8198 from Rafal Rzepecki. Back-patch to all supported branches, since this works fine as far back as 8.4. Rafal Rzepecki and Tom Lane http://git.postgresql.org/pg/commitdiff/a4424c57c3da52efa212b21521abff4bf129b19e
  • Tweak postgres_fdw regression test so autovacuum doesn't change results. Autovacuum occurring while the test runs could allow some of the inserts to go into recycled space, thus changing the output ordering of later queries. While we could complicate those queries to force sorting of their output rows, it doesn't seem like that would make the test better in any meaningful way, and conceivably it could hide unexpected diffs. Instead, tweak the affected queries so that the inserted rows aren't updated by the following UPDATE. Per buildfarm. http://git.postgresql.org/pg/commitdiff/e0b451e43250558b3c1ac830e067b39e25e0e348

Peter Eisentraut a poussé :

Bruce Momjian a poussé :

Robert Haas a poussé :

Kevin Grittner a poussé :

Andrew Dunstan a poussé :

  • Handle Unicode surrogate pairs correctly when processing JSON. In 9.2, Unicode escape sequences are not analysed at all other than to make sure that they are in the form \uXXXX. But in 9.3 many of the new operators and functions try to turn JSON text values into text in the server encoding, and this includes de-escaping Unicode escape sequences. This processing had not taken into account the possibility that this might contain a surrogate pair to designate a character outside the BMP. That is now handled correctly. This also enforces correct use of surrogate pairs, something that is not done by the type's input routines. This fact is noted in the docs. http://git.postgresql.org/pg/commitdiff/94e3311b97448324d67ba9a527854271373329d9
  • Don't downcase non-ascii identifier chars in multi-byte encodings. Long-standing code has called tolower() on identifier character bytes with the high bit set. This is clearly an error and produces junk output when the encoding is multi-byte. This patch therefore restricts this activity to cases where there is a character with the high bit set AND the encoding is single-byte. There have been numerous gripes about this, most recently from Martin Schäfer. Backpatch to all live releases. http://git.postgresql.org/pg/commitdiff/d535136b5d60b19f7ffa777b97ed301739c15a9d

Joe Conway a poussé :

  • Fix ordering of obj id for Rules and EventTriggers in pg_dump. getSchemaData() must identify extension member objects and mark them as not to be dumped. This must happen after reading all objects that can be direct members of extensions, but before we begin to process table subsidiary objects. Both rules and event triggers were wrong in this regard. Backport rules portion of patch to 9.1 -- event triggers do not exist prior to 9.3. Suggested fix by Tom Lane, initial complaint and patch by me. http://git.postgresql.org/pg/commitdiff/33a4466f767be8b153ef1ef78433ad9b1867dab8

Correctifs rejetés (à ce jour)

  • No one was disappointed this week

Correctifs en attente

  • Noah Misch sent in a patch to improve partitioning performance by caching stringToNode() of pg_constraint.ccbin.
  • Robert Haas sent in another revision of a patch to enable MVCC catalog access.
  • Pavel Raiskup sent in a patch to add support for the TAS/S_UNLOCK instructions for aarch64.
  • Michael Paquier sent in another revision of a patch to add support for REINDEX CONCURRENTLY.
  • Andres Freund sent in a WIP patch to add extensible external toast tuples and add the "snappy" compression algorithm as a contrib module.
  • Gurjeet Singh and Heikki Linnakangas traded patches to introduce a new automatic variable to pgbench: client_id.
  • Amit Kapila sent in another revision of a patch to move unused buffers to freelist.
  • Gurjeet Singh sent in another revision of a patch to make processing of long AND/OR lists more efficient.
  • Greg Smith and Heikki Linnakangas traded patches to redesign how checkpoint segments are done.
  • Dean Rasheed sent in two more revisions of a patch to make sure they catalog knows when a relation is updateable.
  • Amit Kapila sent in another revision of a patch to reduce the amount of WAL for an update operation.
  • Greg Smith sent in another revision of a patch to add a --throttle option to pgbench.
  • Simon Riggs sent in a patch to batch trigger executions together to avoid execution overhead.
  • Simon Riggs sent in a patch to make it possible to do ALTER TABLE ... ALTER CONSTRAINT.
  • Dean Rasheed sent in another revision of a patch to add WITH CHECK OPTION to updateable views.
  • Noah Misch sent in a flock of patches dealing with memory errors in 9.3.
  • Noah Misch sent in two more revisions of a patch to do Valgrind memory checking.
  • Tatsuo Ishii sent in a patch to rationalize client-side large object accessors.
  • Jeff Davis sent in another revision of a patch to eliminate PD_ALL_VISIBLE.
  • Jeff Davis sent in a patch to update pg_filedump to deal with current technologies like checksums.