La PostgreSQL Conference 2017 Japan sera tenue le 3 novembre 2017 à Tokyo : https://www.postgresql.jp/events/jpug-pgcon2017

PGConf.ASIA 2017 aura lieu à Akihabara (Tokyo, Japon) du 4 au 6 décembre 2017. Les inscriptions sont ouvertes : http://eventregist.com/e/PGConfASIA2017?lang=en_US http://www.pgconf.asia/EN/2017/

FOSDEM PGDay 2018, une conférence d'une journée tenue avant l'événement principal, sera tenue à Bruxelles (Belgique) le 2 février 2018 : https://2018.fosdempgday.org/

La PGConf US 2018 aura lieu à Jersey City (New Jersey, États-Unis) du 16 au 20 avril 2018. Les candidatures des conférenciers sont attendues avant le 22 janvier 2018. Retour aux candidats le 31 janvier 2018 : https://pgconf.org/conferences/2018

[ndt: MeetUp à Paris le 7 décembre :https://www.meetup.com/fr-FR/PostgreSQL-User-Group-Paris/]

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en octobre

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. La version originale se trouve à l'adresse suivante : http://www.postgresql.org/message-id/20171022180946.GA18828@fetter.org

Submit news and announcements by Sunday at 3:00pm EST5EDT. Please send English language ones to david@fetter.org, German language to pwn@pgug.de, Italian language to pwn@itpug.org.

Correctifs appliqués

Tom Lane pushed:

  • Restore nodeAgg.c's ability to check for improperly-nested aggregates. While poking around in the aggregate logic, I noticed that commit 8ed3f11bb broke the logic in nodeAgg.c that purports to detect nested aggregates, by moving initialization of regular aggregate argument expressions out of the code segment that checks for that. You could argue that this check is unnecessary, but it's not much code so I'm inclined to keep it as a backstop against parser and planner bugs. However, there's certainly zero value in checking only some of the subexpressions. We can make the check complete again, and as a bonus make it a good deal more bulletproof against future mistakes of the same ilk, by moving it out to the outermost level of ExecInitAgg. This means we need to check only once per Agg node not once per aggregate, which also seems like a good thing --- if the check does find something wrong, it's not urgent that we report it before the plan node initialization finishes. Since this requires remembering the original length of the aggs list, I deleted a long-obsolete stanza that changed numaggs from 0 to 1. That's so old it predates our decision that palloc(0) is a valid operation, in (digs...) 2004, see commit 24a1e20f1. In passing improve a few comments. Back-patch to v10, just in case. https://git.postgresql.org/pg/commitdiff/5fc438fb256ce83248feaf60e22e0919b76e3c7b
  • Repair breakage of aggregate FILTER option. An aggregate's input expression(s) are not supposed to be evaluated at all for a row where its FILTER test fails ... but commit 8ed3f11bb overlooked that requirement. Reshuffle so that aggregates having a filter clause evaluate their arguments separately from those without. This still gets the benefit of doing only one ExecProject in the common case of multiple Aggrefs, none of which have filters. While at it, arrange for filter clauses to be included in the common ExecProject evaluation, thus perhaps buying a little bit even when there are filters. Back-patch to v10 where the bug was introduced. Discussion: https://postgr.es/m/30065.1508161354@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/c3dfe0fec01469b8a7de327303cad50ba8ed338a
  • Allow the built-in ordered-set aggregates to share transition state. The built-in OSAs all share the same transition function, so they can share transition state as long as the final functions cooperate to not do the sort step more than once. To avoid running the tuplesort object in randomAccess mode unnecessarily, add a bit of infrastructure to nodeAgg.c to let the aggregate functions find out whether the transition state is actually being shared or not. This doesn't work for the hypothetical aggregates, since those inject a hypothetical row that isn't traceable to the shared input state. So they remain marked aggfinalmodify = 'w'. Discussion: https://postgr.es/m/CAB4ELO5RZhOamuT9Xsf72ozbenDLLXZKSk07FiSVsuJNZB861A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/be0ebb65f51225223421df6e10eb6e87fc8264d7
  • Treat aggregate direct arguments as per-agg data not per-trans data. There is no reason to insist that direct arguments must match before we can merge transition states of two aggregate calls. They're only used during the finalfn call, so we can treat them as like the finalfn itself. This allows, eg, merging of select percentile_cont(0.25) within group (order by a), percentile_disc(0.5) within group (order by a) from ... This didn't matter (and could not have been tested) before we allowed state merging of OSAs otherwise. Discussion: https://postgr.es/m/CAB4ELO5RZhOamuT9Xsf72ozbenDLLXZKSk07FiSVsuJNZB861A@mail.gmail.com https://git.postgresql.org/pg/commitdiff/cf5ba7c30c0428f5ff49197ec1e0f052035300d6
  • Fix incorrect handling of CTEs and ENRs as DML target relations. setTargetTable threw an error if the proposed target RangeVar's relname matched any visible CTE or ENR. This breaks backwards compatibility in the CTE case, since pre-v10 we never looked for a CTE here at all, so that CTE names did not mask regular tables. It does seem like a good idea to throw an error for the ENR case, though, thus causing ENRs to mask tables for this purpose; ENRs are new in v10 so we're not breaking existing code, and we may someday want to allow them to be the targets of DML. To fix that, replace use of getRTEForSpecialRelationTypes, which was overkill anyway, with use of scanNameSpaceForENR. A second problem was that the check neglected to verify null schemaname, so that a CTE or ENR could incorrectly be thought to match a qualified RangeVar. That happened because getRTEForSpecialRelationTypes relied on its caller to have checked for null schemaname. Even though the one remaining caller got it right, this is obviously bug-prone, so move the check inside getRTEForSpecialRelationTypes. Also, revert commit 18ce3a4ab's extremely poorly thought out decision to add a NULL return case to parserOpenTable --- without either documenting that or adjusting any of the callers to check for it. The current bug seems to have arisen in part due to working around that bad idea. In passing, remove the one-line shim functions transformCTEReference and transformENRReference --- they don't seem to be adding any clarity or functionality. Per report from Hugo Mercier (via Julien Rouhaud). Back-patch to v10 where the bug was introduced. Thomas Munro, with minor editing by me Discussion: https://postgr.es/m/CAOBaU_YdPVH+PTtiKSSLOiiW3mVDYsnNUekK+XPbHXiP=wrFLA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/7421f4b89a90e1fa45751dd1cbc4e8d4ca1cba5e
  • Fix incorrect handling of CTEs and ENRs as DML target relations. setTargetTable threw an error if the proposed target RangeVar's relname matched any visible CTE or ENR. This breaks backwards compatibility in the CTE case, since pre-v10 we never looked for a CTE here at all, so that CTE names did not mask regular tables. It does seem like a good idea to throw an error for the ENR case, though, thus causing ENRs to mask tables for this purpose; ENRs are new in v10 so we're not breaking existing code, and we may someday want to allow them to be the targets of DML. To fix that, replace use of getRTEForSpecialRelationTypes, which was overkill anyway, with use of scanNameSpaceForENR. A second problem was that the check neglected to verify null schemaname, so that a CTE or ENR could incorrectly be thought to match a qualified RangeVar. That happened because getRTEForSpecialRelationTypes relied on its caller to have checked for null schemaname. Even though the one remaining caller got it right, this is obviously bug-prone, so move the check inside getRTEForSpecialRelationTypes. Also, revert commit 18ce3a4ab's extremely poorly thought out decision to add a NULL return case to parserOpenTable --- without either documenting that or adjusting any of the callers to check for it. The current bug seems to have arisen in part due to working around that bad idea. In passing, remove the one-line shim functions transformCTEReference and transformENRReference --- they don't seem to be adding any clarity or functionality. Per report from Hugo Mercier (via Julien Rouhaud). Back-patch to v10 where the bug was introduced. Thomas Munro, with minor editing by me Discussion: https://postgr.es/m/CAOBaU_YdPVH+PTtiKSSLOiiW3mVDYsnNUekK+XPbHXiP=wrFLA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/7421f4b89a90e1fa45751dd1cbc4e8d4ca1cba5e
  • Fix incorrect link in v10 release notes. As noted by M. Justin. Also, to keep the HEAD and REL_10 versions of release-10.sgml in sync, back-patch the effects of c29c57890 on that file. We have a bigger problem there though :-( Discussion: https://postgr.es/m/CALtA7pmsQyTTD3fC2rmfUWgfivv5sCJJ84PHY0F_5t_SRc07Qg@mail.gmail.com Discussion: https://postgr.es/m/6d137bd0-eef6-1d91-d9b8-1a5e9195a899@2ndquadrant.com https://git.postgresql.org/pg/commitdiff/e250c8c8408a1c068285df210a7ceff68c421b3b
  • Fix misimplementation of typcache logic for extended hashing. The previous coding would report that an array type supports extended hashing if its element type supports regular hashing. This bug is only latent at the moment, since AFAICS there is not yet any code that depends on checking presence of extended-hashing support to make any decisions. (And in any case it wouldn't matter unless the element type has only regular hashing, which isn't true of any core data type.) But that doesn't make it less broken. Extend the cache_array_element_properties infrastructure to check this properly. https://git.postgresql.org/pg/commitdiff/a8f1efc8ace228b5258ee7d06eace923007072c4
  • Fix typcache's failure to treat ranges as container types. Like the similar logic for arrays and records, it's necessary to examine the range's subtype to decide whether the range type can support hashing. We can omit checking the subtype for btree-defined operations, though, since range subtypes are required to have those operations. (Possibly that simplification for btree cases led us to overlook that it does not apply for hash cases.) This is only an issue if the subtype lacks hash support, which is not true of any built-in range type, but it's easy to demonstrate a problem with a range type over, eg, money: you can get a "could not identify a hash function" failure when the planner is misled into thinking that hash join or aggregation would work. This was born broken, so back-patch to all supported branches. https://git.postgresql.org/pg/commitdiff/36ea99c84d856177ec307307788a279cc600566e

�lvaro Herrera pushed:

Peter Eisentraut pushed:

  • Exclude flex-generated code from coverage testing. Flex generates a lot of functions that are not actually used. In order to avoid coverage figures being ruined by that, mark up the part of the .l files where the generated code appears by lcov exclusion markers. That way, lcov will typically only reported on coverage for the .l file, which is under our control, but not for the .c file. Reviewed-by: Michael Paquier <michael.paquier@gmail.com> https://git.postgresql.org/pg/commitdiff/421167362242ce1fb46d6d720798787e7cd65aad
  • Don't use SGML empty tags. For DocBook XML compatibility, don't use SGML empty tags (</>) anymore, replace by the full tag name. Add a warning option to catch future occurrences. Alexander Lakhin, J�rgen Purtz https://git.postgresql.org/pg/commitdiff/c29c578908dc0271eeb13a4014e54bff07a29c05
  • UCS_to_most.pl: Process encodings in sorted order. Otherwise the order depends on the Perl hash implementation, making it cumbersome to scan the output when debugging. https://git.postgresql.org/pg/commitdiff/927e1ee2cb74e3bc49454dfa181dcce83b70d371
  • Convert SGML IDs to lower case. IDs in SGML are case insensitive, and we have accumulated a mix of upper and lower case IDs, including different variants of the same ID. In XML, these will be case sensitive, so we need to fix up those differences. Going to all lower case seems most straightforward, and the current build process already makes all anchors and lower case anyway during the SGML->XML conversion, so this doesn't create any difference in the output right now. A future XML-only build process would, however, maintain any mixed case ID spellings in the output, so that is another reason to clean this up beforehand. Author: Alexander Lakhin <exclusion@gmail.com> https://git.postgresql.org/pg/commitdiff/1ff01b3902cbf5b22d1a439014202499c21b2994
  • Convert another SGML ID to lower case. The mostly automated conversion in 1ff01b3902cbf5b22d1a439014202499c21b2994 missed this one because of the unusual whitespace. https://git.postgresql.org/pg/commitdiff/7c981590c2e8149a88f6b53829770e2277336879

Magnus Hagander pushed:

Robert Haas pushed:

Correctifs en attente

Amit Khandekar sent in another revision of a patch to enable updates of partition keys to move tuples to the corresponding partition.

Ashutosh Bapat sent in a patch to ignore dropped columns in set_append_rel_size().

Thomas Munro sent in a patch to ensure that EOF doesn't count as a temporary buffer read in EXPLAIN.

Eric Radman sent in two revisions of a patch to add a recovery_min_apply_delay_reconnect recovery option.

Eiji Seki sent in a patch to fix a typo in blvacuum.c.

Thomas Munro sent in a patch to add a GUC to control whether Gather runs subplans.

Masahiko Sawada sent in another revision of a patch to implement block level parallel vacuum.

Masahiko Sawada sent in another revision of a patch to enable custom initialization for pgbench.

Badrul Chowdhury sent in another revision of a patch to enable wire protocol version negotiation.

Amit Langote sent in another revision of a patch to add new tests for partition-pruning, make some planner-side changes for same, implement get_partitions_from_clauses, make some interface changes for partition_bound_{cmp/bsearch}, and implement get_partitions_for_keys.

Amit Khandekar sent in another revision of a patch to implement parallel append.

Nico Williams sent in another revision of a patch to add an ALWAYS DEFERRED option for constraints and constraint triggers.

Tomas Vondra sent in a patch to implement BRIN Bloom indexes.

Tom Lane sent in another revision of a patch to allow creating DOMAINs over composite types.

Yura Sokolov sent in another revision of a patch to fix performance degradation of contended LWLocks on NUMA.

Aleksandr Parfenov sent in two revisions of a patch to create a flexible configuration system for full-text search.

Kyotaro HORIGUCHI sent in another revision of a patch to enable asynchrounous execution in core and implement same in the PostgreSQL foreign data wrapper.

Fabien COELHO sent in another revision of a patch to enable pgbench to use more operators and functions.

Fabien COELHO sent in another revision of a patch to enable pgbench to store select results into variables.

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

Robert Haas sent in another revision of a patch to refactor handling of database attributes between pg_dump and pg_dumpall.

Andrey Borodin sent in a patch to create cube opclass without compress/decompress.