== PostgreSQL Weekly News - August 18, 2019 ==
| От | David Fetter |
|---|---|
| Тема | == PostgreSQL Weekly News - August 18, 2019 == |
| Дата | |
| Msg-id | 20190818185737.GA27102@fetter.org обсуждение исходный текст |
| Список | pgsql-announce |
== PostgreSQL Weekly News - August 18, 2019 == == PostgreSQL Product News == Pgpool-II 4.0.6, 3.7.11, 3.6.18, 3.5.22 and 3.4.25 released. http://pgpool.net/mediawiki/index.php/Downloads PostGIS 3.0.0alpaha4, 2.5.3, 2.4.8, and 2.3.10, the industry standard geographic information system package for PostgreSQL, released. https://postgis.net/2019/08/11/postgis-patches/ temboard 4.0, a management tool for PostgreSQL, released. http://temboard.io/ == PostgreSQL Jobs for August == http://archives.postgresql.org/pgsql-jobs/2019-08/ == PostgreSQL Local == The first Austrian pgDay, will take place September 6, 2019 at the Hilton Garden Inn in Wiener Neustadt. https://pgday.at/en/ PostgresOpen will be September 11th - 13th, 2019 in Orlando, Florida at the Rosen Centre Hotel. The CfP is open at https://2019.postgresopen.org/callforpapers/ https://2019.postgresopen.org/ PostgresConf South Africa 2019 will take place in Johannesburg on October 8-9, 2019 https://postgresconf.org/conferences/SouthAfrica2019 PostgreSQL Conference Europe 2019 will be held on October 15-18, 2019 in Milan, Italy. https://2019.pgconf.eu/ 2Q PGConf 2019 will be held December 4 & 5 in Chicago. The CFP is open through August 30, 2019. https://www.2qpgconf.com/ pgDay Paris 2020 will be held in Paris, France on March 26, 2020 at Espace Saint-Martin. http://2020.pgday.paris/ Nordic PGDay 2020 will be held in Helsinki, Finland at the Hilton Helsinki Strand Hotel on March 24, 2020. The CfP is open through December 31, 2019 at https://2020.nordicpgday.org/cfp/ == 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 PST8PDT to david@fetter.org. == Applied Patches == Alexander Korotkov pushed: - Adjust string comparison in jsonpath. We have implemented jsonpath string comparison using default database locale. However, standard requires us to compare Unicode codepoints. This commit implements that, but for performance reasons we still use per-byte comparison for "==" operator. Thus, for consistency other comparison operators do per-byte comparison if Unicode codepoints appear to be equal. In some edge cases, when same Unicode codepoints have different binary representations in database encoding, we diverge standard to achieve better performance of "==" operator. In future to implement strict standard conformance, we can do normalization of input JSON strings. Original patch was written by Nikita Glukhov, rewritten by me. Reported-by: Markus Winand Discussion: https://postgr.es/m/8B7FA3B4-328D-43D7-95A8-37B8891B8C78%40winand.at Author: Nikita Glukhov, Alexander Korotkov Backpatch-through: 12 https://git.postgresql.org/pg/commitdiff/d54ceb9e176152f930e60709e07c636e8e5414f5 - Fix string comparison in jsonpath. Take into account pg_server_to_any() may return input string "as is". Reported-by: Andrew Dunstan, Thomas Munro Discussion: https://postgr.es/m/0ed83a33-d900-466a-880a-70ef456c721f%402ndQuadrant.com Author: Alexander Korotkov, Thomas Munro Backpatch-through: 12 https://git.postgresql.org/pg/commitdiff/251c8e39bc6b0a3ff1620d9ac10888a7660e6b88 Tom Lane pushed: - Partially revert "Insert temporary debugging output in regression tests.". This reverts much of commit f03a9ca4366d064d89b7cf7ed75d4e43f2ed0667, but leaves the relpages/reltuples probe in select_parallel.sql. The pg_stat_all_tables probes are unstable enough to be annoying, and it no longer seems likely that they will teach us anything more about the underlying problem. I'd still like some more confirmation though that the observed plan instability is caused by VACUUM leaving relpages/reltuples as zero for one of these tables. Discussion: https://postgr.es/m/CA+hUKG+0CxrKRWRMf5ymN3gm+BECHna2B-q1w8onKBep4HasUw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/b43f7c117e667fb51df36ca62e6c86054b0f8d03 - Rationalize use of list_concat + list_copy combinations. In the wake of commit 1cff1b95a, the result of list_concat no longer shares the ListCells of the second input. Therefore, we can replace "list_concat(x, list_copy(y))" with just "list_concat(x, y)". To improve call sites that were list_copy'ing the first argument, or both arguments, invent "list_concat_copy()" which produces a new list sharing no ListCells with either input. (This is a bit faster than "list_concat(list_copy(x), y)" because it makes the result list the right size to start with.) In call sites that were not list_copy'ing the second argument, the new semantics mean that we are usually leaking the second List's storage, since typically there is no remaining pointer to it. We considered inventing another list_copy variant that would list_free the second input, but concluded that for most call sites it isn't worth worrying about, given the relative compactness of the new List representation. (Note that in cases where such leakage would happen, the old code already leaked the second List's header; so we're only discussing the size of the leak not whether there is one. I did adjust two or three places that had been troubling to free that header so that they manually free the whole second List.) Patch by me; thanks to David Rowley for review. Discussion: https://postgr.es/m/11587.1550975080@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/5ee190f8ec37c1bbfb3061e18304e155d600bc8e - Remove EState.es_range_table_array. Now that list_nth is O(1), there's no good reason to maintain a separate array of RTE pointers rather than indexing into estate->es_range_table. Deleting the array doesn't save all that much either; but just on cleanliness grounds, it's better not to have duplicate representations of the identical information. Discussion: https://postgr.es/m/14960.1565384592@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/3c926587b5928795e54dfea65c712a604f63cdeb - Fix planner's test for case-foldable characters in ILIKE with ICU. As coded, the ICU-collation path in pattern_char_isalpha() failed to consider regular ASCII letters to be case-varying. This led to like_fixed_prefix treating too much of an ILIKE pattern as being a fixed prefix, so that indexscans derived from an ILIKE clause might miss entries that they should find. Per bug #15892 from James Inform. This is an oversight in the original ICU patch (commit eccfef81e), so back-patch to v10 where that came in. Discussion: https://postgr.es/m/15892-e5d2bea3e8a04a1b@postgresql.org https://git.postgresql.org/pg/commitdiff/03c811a483b243952874d8e2b3f0c2e3793bc952 - Un-break pg_dump for pre-8.3 source servers. Commit 07b39083c inserted an unconditional reference to pg_opfamily, which of course fails on servers predating that catalog. Fortunately, the case it's trying to solve can't occur on such old servers (AFAIK). Hence, just skip the additional code when the source predates 8.3. Per bug #15955 from sly. Back-patch to all supported branches, like the previous patch. Discussion: https://postgr.es/m/15955-1daa2e676e903d87@postgresql.org https://git.postgresql.org/pg/commitdiff/31d43710fb069a5c2be6ec1dbc9fa7261cf9feff - Fix ALTER SYSTEM to cope with duplicate entries in postgresql.auto.conf. ALTER SYSTEM itself normally won't make duplicate entries (although up till this patch, it was possible to confuse it by writing case variants of a GUC's name). However, if some external tool has appended entries to the file, that could result in duplicate entries for a single GUC name. In such a situation, ALTER SYSTEM did exactly the wrong thing, because it replaced or removed only the first matching entry, leaving the later one(s) still there and hence still determining the active value. This patch fixes that by making ALTER SYSTEM sweep through the file and remove all matching entries, then (if not ALTER SYSTEM RESET) append the new setting to the end. This means entries will be in order of last setting rather than first setting, but that shouldn't hurt anything. Also, make the comparisons case-insensitive so that the right things happen if you do, say, ALTER SYSTEM SET "TimeZone" = 'whatever'. This has been broken since ALTER SYSTEM was invented, so back-patch to all supported branches. Ian Barwick, with minor mods by me Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com https://git.postgresql.org/pg/commitdiff/f1bf619acdff15b88b5729f8de6df4eed609b3a0 - Doc: improve documentation about postgresql.auto.conf. Clarify what external tools can do to this file, and add a bit of detail about what ALTER SYSTEM itself does. Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com https://git.postgresql.org/pg/commitdiff/45aaaa42fefad6e2f164647e373346a5a4123dad - Use a hash table to de-duplicate NOTIFY events faster. Previously, async.c got rid of duplicate notifications by scanning the list of pending events to compare each one to the proposed new event. This works okay for very small numbers of distinct events, but degrades as O(N^2) for many events. We can improve matters by using a hash table to probe for duplicates. So as not to add a lot of overhead for the simple cases that the code did handle well before, create the hash table only once a (sub)transaction has queued more than 16 distinct notify events. A downside is that we now have to do per-event work to propagate a successful subtransaction's notify events up to its parent. (But this isn't significant unless the subtransaction had many events, in which case the O(N^2) behavior would have been in play already, so we still come out ahead.) We can make some lemonade out of this lemon, though: since we must examine each event anyway, it's now possible to de-duplicate events fully, rather than skipping that for events merged up from subtransactions. Hence, remove the old weasel wording in notify.sgml about whether de-duplication happens or not, and adjust the test case in async-notify.spec that exhibited the old behavior. While at it, rearrange the definition of struct Notification to make it more compact and require just one palloc per event, rather than two or three. This saves space when there are a lot of events, in fact more than enough to buy back the space needed for the hash table. Patch by me, based on discussions around a different patch submitted by Filip Rembiałkowski. Discussion: https://postgr.es/m/17822.1564186806@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/bb5ae8f6c4161e1742a90f27b697eeb14812e65f - Fix plpgsql to re-look-up composite type names at need. Commit 4b93f5799 rearranged things in plpgsql to make it cope better with composite types changing underneath it intra-session. However, I failed to consider the case of a composite type being dropped and recreated entirely. In my defense, the previous coding didn't consider that possibility at all either --- but it would accidentally work so long as you didn't change the type's field list, because the built-at-compile-time list of component variables would then still match the type's new definition. The new coding, however, occasionally tries to re-look-up the type by OID, and then fails to find the dropped type. To fix this, we need to save the TypeName struct, and then redo the type OID lookup from that. Of course that's expensive, so we don't want to do it every time we need the type OID. This can be fixed in the same way that 4b93f5799 dealt with changes to composite types' definitions: keep an eye on the type's typcache entry to see if its tupledesc has been invalidated. (Perhaps, at some point, this mechanism should be generalized so it can work for non-composite types too; but for now, plpgsql only tries to cope with intra-session redefinitions of composites.) I'm slightly hesitant to back-patch this into v11, because it changes the contents of struct PLpgSQL_type as well as the signature of plpgsql_build_datatype(), so in principle it could break code that is poking into the innards of plpgsql. However, the only popular extension of that ilk is pldebugger, and it doesn't seem to be affected. Since this is a regression for people who were relying on the old behavior, it seems worth taking the small risk of causing compatibility issues. Per bug #15913 from Daniel Fiori. Back-patch to v11 where 4b93f5799 came in. Discussion: https://postgr.es/m/15913-a7e112e16dedcffc@postgresql.org https://git.postgresql.org/pg/commitdiff/fe9b7b2fe5973309c0a5f7d9240dde91aeeb94aa - Prevent possible double-free when update trigger returns old tuple. This is a variant of the problem fixed in commit 25b692568, which unfortunately we failed to detect at the time. If an update trigger returns the "old" tuple, as it's entitled to do, then a subsequent iteration of the loop in ExecBRUpdateTriggers would have "oldtuple" equal to "trigtuple" and would fail to notice that it shouldn't free that. In addition to fixing the code, extend the test case added by 25b692568 so that it covers multiple-trigger-iterations cases. This problem does not manifest in v12/HEAD, as a result of the relevant code having been largely rewritten for slotification. However, include the test case into v12/HEAD anyway, since this is clearly an area that someone could break again in future. Per report from Piotr Gabriel Kosinski. Back-patch into all supported branches, since the bug seems quite old. Diagnosis and code fix by Thomas Munro, test case by me. Discussion: https://postgr.es/m/CAFMLSdP0rd7LqC3j-H6Fh51FYSt5A10DDh-3=W4PPc4LLUQ8YQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/1ced082b95b339e49fc3d9f15474f816e7a9cfb1 - Make deadlock-parallel isolation test more robust. This test failed fairly reproducibly on some CLOBBER_CACHE_ALWAYS buildfarm animals. The cause seems to be that if a parallel worker is slow enough to reach its lock wait, it may not be released by the first deadlock check run, and then later deadlock checks might decide to unblock the d2 session instead of the d1 session, leaving us in an undetected deadlock state (since the isolationtester client is waiting for d1 to complete first). Fix by introducing an additional lock wait at the end of the d2a1 step, ensuring that the deadlock checker will recognize that d1 has to be unblocked before d2a1 completes. Also reduce max_parallel_workers_per_gather to 3 in this test. With the default max_worker_processes value, we were only getting one parallel worker for the d2a1 step, which is not the case I hoped to test. We should get 3 for d1a2 and 2 for d2a1, as the code stands; and maybe 3 for d2a1 if somebody figures out why the last parallel worker slot isn't free already. Discussion: https://postgr.es/m/22195.1566077308@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/9be4ce4fa33594e035eb421894247e5af61393ce Peter Geoghegan pushed: - amcheck: Skip unlogged relations during recovery. contrib/amcheck failed to consider the possibility that unlogged relations will not have any main relation fork files when running in hot standby mode. This led to low-level "can't happen" errors that complain about the absence of a relfilenode file. To fix, simply skip verification of unlogged index relations during recovery. In passing, add a direct check for the presence of a main fork just before verification proper begins, so that we cleanly verify the presence of the main relation fork file. Author: Andrey Borodin, Peter Geoghegan Reported-By: Andrey Borodin Diagnosed-By: Andrey Borodin Discussion: https://postgr.es/m/DA9B33AC-53CB-4643-96D4-7A0BBC037FA1@yandex-team.ru Backpatch: 10-, where amcheck was introduced. https://git.postgresql.org/pg/commitdiff/6754fe65a4c68c1e3b179080ab62c2f3ff6d877c - Use PageIndexTupleOverwrite() within nbtree. Use the PageIndexTupleOverwrite() bufpage.c routine within nbtree instead of deleting a tuple and re-inserting its replacement. This makes the intent of affected code slightly clearer. It also makes CREATE INDEX slightly faster, since there is no longer a need to shift every leaf page's line pointer array back and forth during index builds. Author: Peter Geoghegan, Anastasia Lubennikova Reviewed-By: Anastasia Lubennikova Discussion: https://postgr.es/m/CAH2-Wz=Zk=B9+Vwm376WuO7YTjFc2SSskifQm4Nme3RRRPtOSQ@mail.gmail.com https://git.postgresql.org/pg/commitdiff/af0ba49809b57203d87702b315b64f1fd53c728d - Remove obsolete nbtree README commentary. Commit d2086b08b02 removed almost all cases where nbtree must release a read buffer lock and acquire a write buffer lock instead, so remaining cases in which that's still necessary are not notable enough to appear in the nbtree README. More importantly, holding on to a buffer pin in cases where nbtree must trade a read lock for a write lock is very unlikely to save any I/O. This seems to have been a long overlooked throwback to a time when nbtree cared about write-ordering dependencies, and performed synchronous buffer writes. It hasn't worked that way in many years. https://git.postgresql.org/pg/commitdiff/68ef887842ff716097bbb1bad86a40bb62247061 - Remove block number field from nbtree stack. The initial value of the nbtree stack downlink block number field recorded during an initial descent of the tree wasn't actually used. Both _bt_getstackbuf() callers overwrote the value with their own value. Remove the block number field from the stack struct, and add a child block number argument to _bt_getstackbuf() in its place. This makes the overall design of _bt_getstackbuf() clearer. Author: Peter Geoghegan Reviewed-By: Anastasia Lubennikova Discussion: https://postgr.es/m/CAH2-Wzmx+UbXt2YNOUCZ-a04VdXU=S=OHuAuD7Z8uQq-PXTYUg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/9c02cf56614366769682bb8b3f4e9eecf8f237c4 Michaël Paquier pushed: - Fix random regression failure in test case "temp". This test case could fail because of an incorrect result ordering when looking up at pg_class entries. This commit adds an ORDER BY to the culprit query. The cause of the failure was likely caused by a plan switch. By default, the planner would likely choose an index-only scan or an index scan, but even a small change in the startup cost could have caused a bitmap heap scan to be chosen, causing the failure. While on it, switch some filtering quals to a regular expression as per an idea of Tom Lane. As previously shaped, the quals would have selected any relations whose name begins with "temp". And that could cause failures if another test running in parallel began to use similar relation names. Per report from buildfarm member anole, though the failure was very rare. This test has been introduced by 319a810, so backpatch down to v10. Discussion: https://postgr.es/m/20190807132422.GC15695@paquier.xyz Backpatch-through: 10 https://git.postgresql.org/pg/commitdiff/2d7d67cc74d0f59e76464bd5009bc74f1591018e - Fix inconsistencies and typos in the tree, take 10. This addresses some issues with unnecessary code comments, fixes various typos in docs and comments, and removes some orphaned structures and definitions. Author: Alexander Lakhin Discussion: https://postgr.es/m/9aabc775-5494-b372-8bcb-4dfc0bd37c68@gmail.com https://git.postgresql.org/pg/commitdiff/66bde49d96a9ddacc49dcbdf1b47b5bd6e31ead5 - Fix random regression failure in test case "collate.icu.utf8". This is a fix similar to 2d7d67cc, where slight plan alteration can cause a random failure of this regression test because of an incorect tuple ordering, except that this one involves lookups of pg_type. Similarly to the other case, add ORDER BY clauses to ensure the output order. The failure has been seen at least once on buildfarm member skink. Reported-by: Thomas Munro Discussion: https://postgr.es/m/CA+hUKGLjR9ZBvhXcr9b-NSBHPw9aRgbjyzGE+kqLsT4vwX+nkQ@mail.gmail.com Backpatch-through: 12 https://git.postgresql.org/pg/commitdiff/96e7e1bc08919ceb34d95140834f0db94266da2e Peter Eisentraut pushed: - Update to DocBook 4.5. This moves us to the latest minor version of DocBook 4. It requires no markup changes. https://git.postgresql.org/pg/commitdiff/416c75cf38fbf58f4589fb27b520b64092a7ceff - initdb: Remove obsolete locale handling. The method of passing LC_COLLATE and LC_CTYPE to the backend during initdb is obsolete as of 61d967498802ab86d8897cb3c61740d7e9d712f6. This can all be removed. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/eeaf2f99-a1a6-8aca-3f43-9ab0b2fb112a%402ndquadrant.com https://git.postgresql.org/pg/commitdiff/fded4773eb60541c6e7dbcf09c9bcb1cd36a063b - Improve Assert output. If an assertion expression contained a macro, the failed assertion message would print the expanded macro, which is usually unhelpful and confusing. Restructure the Assert macros to not expand any macros when constructing the failure message. This also fixes that the existing output for Assert et al. shows the *inverted* condition, which is also confusing and not how assertions usually work. Discussion: https://www.postgresql.org/message-id/flat/6c68efe3-117a-dcc1-73d4-18ba1ec532e2%402ndquadrant.com https://git.postgresql.org/pg/commitdiff/d78d452bc5ac46a970e4fca2b31f3d533815c39a - Remove obsolete reference to Irix. https://git.postgresql.org/pg/commitdiff/7e78c872dd5b0f53bbeed90c2b6e610c14e9be4b Álvaro Herrera pushed: - Don't constraint-exclude partitioned tables as much. We only need to invoke constraint exclusion on partitioned tables when they are a partition, and they themselves contain a default partition; it's not necessary otherwise, and it's expensive, so avoid it. Also, we were trying once for each clause separately, but we can do it for all the clauses at once. While at it, centralize setting of RelOptInfo->partition_qual instead of computing it in slightly different ways in different places. Per complaints from Simon Riggs about 4e85642d935e; reviewed by Yuzuko Hosoya, Kyotaro Horiguchi. Author: Amit Langote. I (Álvaro) again mangled the patch somewhat. Discussion: https://postgr.es/m/CANP8+j+tMCY=nEcQeqQam85=uopLBtX-2vHiLD2bbp7iQQUKpA@mail.gmail.com https://git.postgresql.org/pg/commitdiff/815ef2f568c754dcb539cca574f1982317d74db6 Etsuro Fujita pushed: - Remove useless bms_free() calls in build_child_join_rel(). These seem to be leftovers from the original partitionwise-join patch, perhaps. Discussion: https://postgr.es/m/CAPmGK145YiMTPRnvev1dLz8na_-0aZ=Xyqn8f2QsJFBUTObNow@mail.gmail.com https://git.postgresql.org/pg/commitdiff/076e9d42099d092475ea9eaa2902ba101a27a585 Andres Freund pushed: - Remove redundant prototypes for SQL callable functions. These aren't needed after 352a24a1f9d6. The remaining prototypes are not defined on the SQL level. Author: Andres Freund Discussion: https://postgr.es/m/20190803193733.g3l3x3o42uv4qj7l@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/0ae2dc4db2ae9940ab2bb1e4f4c0ff27f09f8aae - Don't include utils/array.h from acl.h. For most uses of acl.h the details of how "Acl" internally looks like are irrelevant. It might make sense to move a lot of the implementation details into a separate header at a later point. The main motivation of this change is to avoid including fmgr.h (via array.h, which needs it for exposed structs) in a lot of files that otherwise don't need it. A subsequent commit will remove the fmgr.h include from a lot of files. Directly include utils/array.h and utils/expandeddatum.h from the files that need them, but previously included them indirectly, via acl.h. Author: Andres Freund Discussion: https://postgr.es/m/20190803193733.g3l3x3o42uv4qj7l@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/6a04d345fd8094058f08344af93022566222733a - Remove fmgr.h includes from headers that don't really need it. Most of the fmgr.h includes were obsoleted by 352a24a1f9d6f7d4abb1. A few others can be obsoleted using the underlying struct type in an implementation detail. Author: Andres Freund Discussion: https://postgr.es/m/20190803193733.g3l3x3o42uv4qj7l@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/fb3b098fe88441f9531a5169008ea17eac01301f - Add missing fmgr.h include. https://git.postgresql.org/pg/commitdiff/00a5c4c17b76b2d68fab70ec0be0960590a3a7fe - Add default_table_access_method to postgresql.conf.sample. Reported-By: Heikki Linnakangas Author: Michael Paquier Discussion: https://postgr.es/m/d6ffbebb-a0d2-181c-811d-b029b2225ed7@iki.fi Backpatch: 12-, where pluggable table access methods were introduced https://git.postgresql.org/pg/commitdiff/f7db0ac7d5b6ba9728616a1cc36288cb4f817e66 == Pending Patches == Alexander Lakhin sent in another revision of a patch to fix typos and inconsistencies. KaiGai Kohei sent in a patch to add a hook which allows extension to provide an extra decision whether add_path() retains the dominated path by other new path, from different dimensions. Alexander Korotkov sent in a patch to improve checking for missing parent links by traversing from one downlink to subsequent using rightlinks instead of collecting lossy bitmap. Kasahara Tatsuhito sent in a patch to shorten the elapsed time for truncating the heap during VACUUM. Peter Eisentraut sent in another revision of a patch to add backtrace support. Fabien COELHO sent in a patch to rework variable management in pgbench. Peter Eisentraut sent in another revision of a patch to add UNIX domain socket support to Windows. Dmitry Igrishin sent in another revision of a patch to fix the build on Windows. Anastasia Lubennikova sent in another revision of a patch to add a wait_for_archive option to pg_stop_backup(). Peter Eisentraut sent in another revision of a patch to add explicit_bzero(). Konstantin Knizhnik sent in two more revisions of a patch to add a built-in connection pooler. Anastasia Lubennikova sent in two more revisions of a patch to compress and deduplicate in nbtree. Dilip Kumar sent in another revision of a patch to create an UNDO interface layer. Konstantin Knizhnik sent in another revision of a patch to implement global temporary tables. David Rowley sent in a patch to call table_finish_bulk_insert less often. Yuli Khodorkovskiy sent in a patch to add a hook to allow extensions to set worker metadata and refactor child process startup using same. Tom Lane sent in another revision of a patch to detect duplicate NOTIFYs by hashing and make a better notification structure. Tom Lane sent in a patch to use the data directory inode for IPC keys. Peter Eisentraut sent in a patch to enable the cluster owner to bypass authentication. Heikki Linnakangas sent in another revision of a patch to implement Zedstore. Andrey Borodin sent in a patch to do rightlink verification with lock coupling in amcheck nbtree. Etsuro Fujita sent in a patch to remove some useless bms_free calls. Masahiko Sawada sent in another revision of a patch to implement table-level transparent data encryption. PSS sent in another revision of a patch to add type info support functions for functions that use the "any" type. Etsuro Fujita sent in another revision of a patch to modify the partition-matching algorithm. Jeevan Chalke sent in another revision of a patch to add support for incremental backup. Álvaro Herrera sent in a WIP patch to patch to use huge pallocs on encoding conversions. Gareth Palmer sent in another revision of a patch to implement the INSERT ... SET syntax, which pairs column names with their values. Binguo Bao sent in another revision of a patch to de-TOAST using an iterator. Peter Eisentraut sent in a patch to clean up SCRAM attribute processing by correcting the comment for read_any_attr(), and giving a clearer error message when parsing at the end of the string when the client-final-message does not contain a "p" attribute (for some reason). Daniel Migowski sent in a patch to add a new GUC, prepared_statement_limit, to limit the memory used by prepared statements. Tara sent in a patch to clarify the docs for creating a role. Noah Misch sent in another revision of a patch to to fix a WAL-logging issue that dates back to 9.4.3. Juan José Santamaría Flecha sent in a patch to make it possible to use localized month names in to_date() and to_timestamp(). Fabien COELHO sent in a PoC patch to make it possible to create a full set of partitions at creation time of a partitioned table. This is especially helpful with hash partitions, which don't really exist in isolation. Nino Floris sent in a patch to add binary protocol support for ltree, lquery, and ltxtquery. Tom Lane sent in a patch to add a shell program which checks headers for duplication.
В списке pgsql-announce по дате отправления:
Предыдущее
От: Bo PengДата:
Сообщение: Pgpool-II 4.0.6, 3.7.11, 3.6.18, 3.5.22 and 3.4.25 are nowofficially released.