== PostgreSQL Weekly News - October 22 2017 == PotgreSQL Conference 2017 Japan will be held on November 3rd, 2017 in Tokyo. https://www.postgresql.jp/events/jpug-pgcon2017
PGConf.ASIA 2017 will take place on December 4-6 2017 in Akihabara, Tokyo, Japan. Registration is open at http://eventregist.com/e/PGConfASIA2017?lang=en_US http://www.pgconf.asia/EN/2017/ FOSDEM PGDay 2018, a one day conference held before the main FOSDEM event will be held in Brussels, Belgium, on Feb 2nd, 2018. https://2018.fosdempgday.org/ == PostgreSQL Product News == PostgresDAC 3.3.0, a direct access component suite for PostgreSQL, released. http://microolap.com/products/connectivity/postgresdac/download/ PGConf US 2018 will be held in Jersey City, NJ, USA April 16-20, 2018. The CfP will be open until January 22, 2018. Speaker notification: January 31, 2018. https://pgconf.org/conferences/2018 Pgpool-II 3.7 beta1 released. http://www.pgpool.net/docs/pgpool-II-3.7.0/doc/en/html/release-3-7.html PostGIS 2.2.6, 2.3.4, and 2.4.1, the industry standard geographic information system package for PostgreSQL, released. http://postgis.net/2017/10/18/postgis-patches/ == PostgreSQL Jobs for October == http://archives.postgresql.org/pgsql-jobs/2017-10/ == PostgreSQL Local == PostgreSQL Conference Europe 2017 will be held on October 24-27, 2017 in the Warsaw Marriott Hotel, in Warsaw, Poland. https://2017.pgconf.eu/ pgday.Seoul 2017 will be held in Seoul, South Korea on November 4, 2017. Korean language information is here: http://pgday.postgresql.kr/ 2ndQuadrant PostgreSQL Conference 2017 (2Q PGConf, for short) will be hosted on November 6th & 7th in New York City, and November 9th in Chicago. http://www.2qpgconf.com/ PGConf Local: Seattle will be held November 13 - 14, 2017. https://www.pgconf.us/#Seattle2017 PGDay Australia 2017 will be held on November 17 in Melbourne. http://2017.pgday.com.au/ PostgreSQL Session will take place November 17th, 2017, in Paris, France. http://www.postgresql-sessions.org/en/9/start PGDAY Brasilia 2017 will take place December 2, 2017. The CfP is open at http://www.pgdaybrasilia.com.br/submissao-de-palestra/ PGConf Local: Austin will be held December 4 - 5, 2017. Call for Papers is now open at https://www.pgconf.us/conferences/Austin2017 PGConf.ASIA 2017 will take place on December 4-6 2017 in Akihabara, Tokyo, Japan. http://www.pgconf.asia/EN/2017/ PGConf India 2018 will be on February 22-23, 2018 in Bengaluru, Karnataka. Proposals are due via https://goo.gl/forms/F9hRjOIsaNasVOAz2 by October 31st, 2017. http://pgconf.in/ PostgreSQL@SCaLE is a two day, two track event which takes place on March 8-9, 2018, at Pasadena Convention Center, as part of SCaLE 16X. The CfP is open through October 31, 2017 at http://www.socallinuxexpo.org/scale/16x/cfp PGConf APAC 2018 will be held in Singapore March 22-24, 2018. The CfP is open at http://2018.pgconfapac.org/cfp through December 4, 2017. http://2018.pgconfapac.org/ == PostgreSQL in the News == Planet PostgreSQL: http://planet.postgresql.org/ PostgreSQL Weekly News is brought to you this week by David Fetter Submit news and announcements by Sunday at 3:00pm EST5EDT. Please send English language ones to da...@fetter.org, German language to p...@pgug.de, Italian language to p...@itpug.org. == Applied Patches == 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.1508161...@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/cab4elo5rzhoamut9xsf72ozbendllxzksk07fisvsujnzb8...@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/cab4elo5rzhoamut9xsf72ozbendllxzksk07fisvsujnzb8...@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=wr...@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=wr...@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_src0...@mail.gmail.com Discussion: https://postgr.es/m/6d137bd0-eef6-1d91-d9b8-1a5e9195a...@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: - Rework DefineIndex relkind check. Simplify coding using a switch rather than nested if tests. Author: Álvaro Reviewed-by: Robert Haas, Amit Langote, Michaël Paquier Discussion: https://postgr.es/m/20171013163820.pai7djcaxrntaxtn@alvherre.pgsql https://git.postgresql.org/pg/commitdiff/60a1d96ed7ba0930024af696e1fb209a030b6c42 - REASSIGN OWNED BY doc: s/privileges/membership/. Reported by: David G. Johnston Discussion: https://postgr.es/m/cakfquwajwqjqel9xc1xnnmtybg32edazkjxijzigbosgss_...@mail.gmail.com https://git.postgresql.org/pg/commitdiff/6ecabead4b5993c42745f2802d857b1a79f48bf9 - Make release notes aware that --xlog-method was renamed. Author: David G. Johnston Discussion: https:/postgr.es/m/cakfquwacsb-okojqxgen0r7byxirwvr7otykdbjoygif2vb...@mail.gmail.com https://git.postgresql.org/pg/commitdiff/f5b73093339d965744607b786d7c34bf8f430935 - Make OWNER TO subcommand mention consistent. We say 'OWNER TO' in the synopsis; let's use that form elsewhere. There is a paragraph in the <note> section that refers to various subcommands very loosely (including OWNER); I didn't think it was an improvement to change that one. This is a fairly inconsequential change, so no backpatch. Author: Amit Langote Discussion: https://postgr.es/m/69ec7b51-03e5-f523-95ce-c070ee790...@lab.ntt.co.jp https://git.postgresql.org/pg/commitdiff/bf54c0f05c0a58db17627724a83e1b6d4ec2712c - Add more tests for reloptions. This is preparation for a future patch to extensively change how reloptions work. Author: Nikolay Shaplov Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/2615372.orqtEn8VGB@x200m https://git.postgresql.org/pg/commitdiff/4b95cc1dc36c9d1971f757e9b519fcc442833f0e 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.paqu...@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 <exclus...@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: - Fix typo in release notes. Spotted by Piotr Stefaniak https://git.postgresql.org/pg/commitdiff/bcf2e5ceb0998318deb36911b13677e88d45c8b4 - Fix typo. Masahiko Sawada https://git.postgresql.org/pg/commitdiff/275c4be19deec4288c303cc9ba3a3540bd1b8f5f - Fix typos. David Rowley https://git.postgresql.org/pg/commitdiff/752871b6de9b4c7d2c685a059adb55887e169201 Robert Haas pushed: - pg_stat_statements: Add a comment about the dangers of padding bytes. Inspired by a patch from Julien Rouhaud, but I reworded it. Discussion: http://postgr.es/m/CAOBaU_a8AH8=ypfqgHnDYu06ts+jWTUgh=vgcxa3ynv-k10...@mail.gmail.com https://git.postgresql.org/pg/commitdiff/2959213bf33cf7d2d1fc0b46c67d36254ffe043f == Pending Patches == 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. -- Sent via pgsql-announce mailing list (pgsql-announce@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-announce
