[ndt: MeetUp à Lyon le 28 février : https://www.meetup.com/fr-FR/PostgreSQL-Lyon-User-Group/]

Les nouveautés des produits dérivés

Offres d'emplois autour de PostgreSQL en janvier

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/20180114200909.GA11243@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

Tom Lane pushed:

  • Back off chattiness in RemovePgTempFiles(). In commit 561885db0, as part of normalizing RemovePgTempFiles's error handling, I removed its behavior of silently ignoring ENOENT failures during directory opens. Thomas Munro points out that this is a bad idea at the top level, because we don't create pgsql_tmp directories until needed. Thus this coding could produce LOG messages in perfectly normal situations, which isn't what I intended. Restore the suppression of ENOENT logging, but only at top level --- it would still be unexpected for a nested temp directory to disappear between seeing it in the parent directory and opening it. Discussion: https://postgr.es/m/CAEepm=2y06SehAkTnd5sU_eVqdv5P-=Srt1y5vYNQk6yVDVaPw@mail.gmail.com https://git.postgresql.org/pg/commitdiff/eeb3c2df429c943b2f8d028d110b55ac0a53dc75
  • Cosmetic improvements in condition_variable.[hc]. Clarify a bunch of comments. Discussion: https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/e35dba475a440f73dccf9ed1fd61e3abc6ee61db
  • Improve error detection capability in proclists. Previously, although the initial state of a proclist_node is expected to be next == prev == 0, proclist_delete_offset would reset nodes to next == prev == INVALID_PGPROCNO when removing them from a list. This is the same state that a node in a singleton list has, so that it's impossible to distinguish not-in-a-list from in-a-list. Change proclist_delete_offset to reset removed nodes to next == prev == 0, making it possible to distinguish those cases, and then add Asserts to the list add and delete functions that the supplied node isn't or is in a list at entry. Also tighten assertions about the node being in the particular list (not some other one) where it is possible to check that in O(1) time. In ConditionVariablePrepareToSleep, since we don't expect the process's cvWaitLink to already be in a list, remove the more-or-less-useless proclist_contains check; we'd rather have proclist_push_tail's new assertion fire if that happens. Improve various comments related to proclists, too. Patch by me, reviewed by Thomas Munro. This isn't back-patchable, since there could theoretically be inlined copies of proclist_delete_offset in third-party modules. But it's only improving debuggability anyway. Discussion: https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com https://git.postgresql.org/pg/commitdiff/ea8e1bbc538444d373cf712a0f5188c906b71a9d
  • Allow ConditionVariable[PrepareTo]Sleep to auto-switch between CVs. The original coding here insisted that callers manually cancel any prepared sleep for one condition variable before starting a sleep on another one. While that's not a huge burden today, it seems like a gotcha that will bite us in future if the use of condition variables increases; anything we can do to make the use of this API simpler and more robust is attractive. Hence, allow these functions to automatically switch their attention to a different CV when required. This is safe for the same reason it was OK for commit aced5a92b to let a broadcast operation cancel any prepared CV sleep: whenever we return to the other test-and-sleep loop, we will automatically re-prepare that CV, paying at most an extra test of that loop's exit condition. Back-patch to v10 where condition variables were introduced. Ordinarily we would probably not back-patch a change like this, but since it does not invalidate any coding pattern that was legal before, it seems safe enough. Furthermore, there's an open bug in replorigin_drop() for which the simplest fix requires this. Even if we chose to fix that in some more complicated way, the hazard would remain that we might back-patch some other bug fix that requires this behavior. Patch by me, reviewed by Thomas Munro. Discussion: https://postgr.es/m/2437.1515368316@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/13db3b936359eebf02a768db3a1959af880b6cc6
  • Fix race condition during replication origin drop. replorigin_drop() misunderstood the API for condition variables: it had ConditionVariablePrepareToSleep and ConditionVariableCancelSleep inside its test-and-sleep loop, rather than outside the loop as intended. The net effect is a narrow race-condition window wherein, if the process using a replication slot releases it immediately after replorigin_drop() releases the ReplicationOriginLock, replorigin_drop() would get into the condition variable's wait list too late and then wait indefinitely for a signal that won't come. Because there's a different CV for each replication slot, we can't just move the ConditionVariablePrepareToSleep call to above the test-and-sleep loop. What we can do, in the wake of commit 13db3b936, is drop the ConditionVariablePrepareToSleep call entirely. This fix depends on that commit because (at least in principle) the slot matching the target replication origin might move around, so that once in a blue moon successive loop iterations might involve different CVs. We can now cope with such a scenario, at the cost of an extra trip through the retry loop. (There are ways we could fix this bug without depending on that commit, but they're all a lot more complicated than this way.) While at it, upgrade the rather skimpy comments in this function. Back-patch to v10 where this code came in. Discussion: https://postgr.es/m/19947.1515455433@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/8a906204aec44de6d8a1514082870f25085d9431
  • While waiting for a condition variable, detect postmaster death. The general assumption for postmaster child processes is that they should just exit(1), reasonably promptly, if the postmaster disappears. condition_variable.c neglected this consideration and could be left waiting forever, if the counterpart process it is waiting for has done the right thing and exited. We had some discussion of adjusting the WaitEventSet API to make it harder to make this type of mistake in future; but for the moment, and for v10, let's make this narrow fix. Discussion: https://postgr.es/m/20412.1515456143@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/80259d4dbf47d13ef4c105e06c4ea084639d9466
  • Rewrite list_qsort() to avoid trashing its input list. The initial implementation of list_qsort(), from commit ab7271677, re-used the ListCells of the input list while not touching the List header. This meant that anybody who still had a pointer to the original header would now be in possession of a corrupted list, a problem that seems sure to bite us eventually. One possible solution is to re-use the original List header as well, giving the function the semantics of update-in-place. However, that doesn't seem like a very good idea either given the way that the function is used in the planner: create_path functions aren't normally supposed to modify their input lists. It doesn't look like there would be a problem today, but it's not hard to foresee a time when modifying a list of Paths in-place could have side-effects on some other append path. On the whole, and in view of the likelihood that this function might be used in other contexts in the future, it seems best to get rid of the micro-optimization of re-using the input list cells. Just build a new list. Discussion: https://postgr.es/m/16912.1515449066@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/3cb1b2a8804da8365fe17f687d96b720df4a583d
  • Improve the heuristic for ordering child paths of a parallel append. Commit ab7271677 introduced code that attempts to order the child scans of a Parallel Append node in a way that will minimize execution time, based on total cost and startup cost. However, it failed to think hard about what to do when estimated costs are exactly equal; a case that's particularly likely to occur when comparing on startup cost. In such a case the ordering of the child paths would be left to the whims of qsort, an algorithm that isn't even stable. We can improve matters by applying the rule used elsewhere in the planner: if total costs are equal, sort on startup cost, and vice versa. When both cost estimates are exactly equal, rather than letting qsort do something unpredictable, sort based on the child paths' relids, which should typically result in sorting in inheritance order. (The latter provision requires inventing a qsort-style comparator for bitmapsets, but maybe we'll have use for that for other reasons in future.) This results in a few plan changes in the select_parallel test, but those all look more reasonable than before, when the actual underlying cost numbers are taken into account. Discussion: https://postgr.es/m/4944.1515446989@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/624e440a474420fa0d6cf26c19bfb256547ab71d
  • Remove dubious micro-optimization in ckpt_buforder_comparator(). It seems incorrect to assume that the list of CkptSortItems can never contain duplicate page numbers: concurrent activity could result in some page getting dropped from a low-numbered buffer and later loaded into a high-numbered buffer while BufferSync is scanning the buffer pool. If that happened, the comparator would give self-inconsistent results, potentially confusing qsort(). Saving one comparison step is not worth possibly getting the sort wrong. So far as I can tell, nothing would actually go wrong given our current implementation of qsort(). It might get a bit slower than expected if there were a large number of duplicates of one value, but that's surely a probability-epsilon case. Still, the comment is wrong, and if we ever switched to another sort implementation it might be less forgiving. In passing, avoid casting away const-ness of the argument pointers; I've not seen any compiler complaints from that, but it seems likely that some compilers would not like it. Back-patch to 9.6 where this code came in, just in case I've underestimated the possible consequences. Discussion: https://postgr.es/m/18437.1515607610@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/3afd75eaac8aaccf5aeebc52548c396b84d85516
  • Fix sample INSTR() functions in the plpgsql documentation. These functions are stated to be Oracle-compatible, but they weren't. Yugo Nagata noticed that while our code returns zero for a zero or negative fourth parameter (occur_index), Oracle throws an error. Further testing by me showed that there was also a discrepancy in the interpretation of a negative third parameter (beg_index): Oracle thinks that a negative beg_index indicates the last place where the target substring can *begin*, whereas our code thinks it is the last place where the target can *end*. Adjust the sample code to behave like Oracle in both these respects. Also change it to be a CDATA[] section, simplifying copying-and-pasting out of the documentation source file. And fix minor problems in the introductory comment, which wasn't very complete or accurate. Back-patch to all supported branches. Although this patch only touches documentation, we should probably call it out as a bug fix in the next minor release notes, since users who have adopted the functions will likely want to update their versions. Yugo Nagata and Tom Lane Discussion: https://postgr.es/m/20171229191705.c0b43a8c.nagata@sraoss.co.jp https://git.postgresql.org/pg/commitdiff/3c1e9fd23269849e32c73683a8457fb3095309e3
  • Cosmetic fix in postgres_fdw.c. Make the forward declaration of estimate_path_cost_size match its actual definition. Tatsuro Yamada Discussion: https://postgr.es/m/96f2f554-1eeb-fe6f-e0db-650771886781@lab.ntt.co.jp https://git.postgresql.org/pg/commitdiff/9ff4f758ee430dbce0be13ab5da315be52cb6f55
  • Add QueryEnvironment to ExplainOneQuery_hook's parameter list. This should have been done in commit 18ce3a4ab, which added that parameter to ExplainOneQuery, but it was overlooked. This makes it impossible for a user of the hook to pass the queryEnv down to ExplainOnePlan. It's too late to change this API in v10, I suppose, but fortunately passing NULL to ExplainOnePlan will work in nearly all interesting cases in v10. That might not be true forever, so we'd better fix it. Tatsuro Yamada, reviewed by Thomas Munro Discussion: https://postgr.es/m/890e8dd9-c1c7-a422-6892-874f5eaee048@lab.ntt.co.jp https://git.postgresql.org/pg/commitdiff/4d41b2e0926548e338d20875729a55d41289f867
  • Fix incorrect handling of subquery pullup in the presence of grouping sets. If we flatten a subquery whose target list contains constants or expressions, when those output columns are used in GROUPING SET columns, the planner was capable of doing the wrong thing by merging a pulled-up expression into the surrounding expression during const-simplification. Then the late processing that attempts to match subexpressions to grouping sets would fail to match those subexpressions to grouping sets, with the effect that they'd not go to null when expected. To fix, wrap such subquery outputs in PlaceHolderVars, ensuring that they preserve their separate identity throughout the planner's expression processing. This is a bit of a band-aid, because the wrapper defeats const-simplification even in places where it would be safe to allow. But a nicer fix would likely be too invasive to back-patch, and the consequences of the missed optimizations probably aren't large in most cases. Back-patch to 9.5 where grouping sets were introduced. Heikki Linnakangas, with small mods and better test cases by me; additional review by Andrew Gierth Discussion: https://postgr.es/m/7dbdcf5c-b5a6-ef89-4958-da212fe10176@iki.fi https://git.postgresql.org/pg/commitdiff/90947674fc984f5639e3b1bf013435a023aa713b
  • Avoid unnecessary failure in SELECT concurrent with ALTER NO INHERIT. If a query against an inheritance tree runs concurrently with an ALTER TABLE that's disinheriting one of the tree members, it's possible to get a "could not find inherited attribute" error because after obtaining lock on the removed member, make_inh_translation_list sees that its columns have attinhcount=0 and decides they aren't the columns it's looking for. An ideal fix, perhaps, would avoid including such a just-removed member table in the query at all; but there seems no way to accomplish that without adding expensive catalog rechecks or creating a likelihood of deadlocks. Instead, let's just drop the check on attinhcount. In this way, a query that's included a just-disinherited child will still succeed, which is not a completely unreasonable behavior. This problem has existed for a long time, so back-patch to all supported branches. Also add an isolation test verifying related behaviors. Patch by me; the new isolation test is based on Kyotaro Horiguchi's work. Discussion: https://postgr.es/m/20170626.174612.23936762.horiguchi.kyotaro@lab.ntt.co.jp https://git.postgresql.org/pg/commitdiff/680d540502609b422d378a1b8e0c10cac3c60084
  • Fix postgres_fdw to cope with duplicate GROUP BY entries. Commit 7012b132d, which added the ability to push down aggregates and grouping to the remote server, wasn't careful to ensure that the remote server would have the same idea we do about which columns are the grouping columns, in cases where there are textually identical GROUP BY expressions. Such cases typically led to "targetlist item has multiple sortgroupref labels" errors. To fix this reliably, switch over to using "GROUP BY column-number" syntax rather than "GROUP BY expression" in transmitted queries, and adjust foreign_grouping_ok() to be more careful about duplicating the sortgroupref labeling of the local pathtarget. Per bug #14890 from Sean Johnston. Back-patch to v10 where the buggy code was introduced. Jeevan Chalke, reviewed by Ashutosh Bapat Discussion: https://postgr.es/m/20171107134948.1508.94783@wrigleys.postgresql.org https://git.postgresql.org/pg/commitdiff/e9f2703ab7b29f7e9100807cfbd19ddebbaa0b12

Bruce Momjian pushed:

Robert Haas pushed:

Peter Eisentraut pushed:

  • Fix ssl tests for when tls-server-end-point is not supported. Add a function to TestLib that allows us to check pg_config.h and then decide the expected test outcome based on that. Author: Michael Paquier <michael.paquier@gmail.com> https://git.postgresql.org/pg/commitdiff/c3d41ccf5931a2e587d114d9886717df76459a9d
  • Update portal-related memory context names and API. Rename PortalMemory to TopPortalContext, to avoid confusion with PortalContext and align naming with similar top-level memory contexts. Rename PortalData's "heap" field to portalContext. The "heap" naming seems quite antiquated and confusing. Also get rid of the PortalGetHeapMemory() macro and access the field directly, which we do for other portal fields, so this abstraction doesn't buy anything. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> https://git.postgresql.org/pg/commitdiff/0f7c49e85518dd846ccd0a044d49a922b9132983
  • Remove PortalGetQueryDesc(). After having gotten rid of PortalGetHeapMemory(), there seems little reason to keep one Portal access macro around that offers no actual abstraction and isn't consistently used anyway. Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com> Reviewed-by: Alvaro Herrera <alvherre@alvh.no-ip.org> https://git.postgresql.org/pg/commitdiff/a77dd53f3089a3d6bf74966bfd3ab7e27537183b
  • Give more accurate error message for dropping pinned portal. The previous code gave the same error message for attempting to drop pinned and active portals, but those are separate states, so give separate error messages. https://git.postgresql.org/pg/commitdiff/acc67ffd0a8c728b928958e75b76ee544b64c2d8
  • Move portal pinning from PL/pgSQL to SPI. PL/pgSQL "pins" internally generated (unnamed) portals so that user code cannot close them by guessing their names. This logic is also useful in other languages and really for any code. So move that logic into SPI. An unnamed portal obtained through SPI_cursor_open() and related functions is now automatically pinned, and SPI_cursor_close() automatically unpins a portal that is pinned. In the core distribution, this affects PL/Perl and PL/Python, preventing users from manually closing cursors created by spi_query and plpy.cursor, respectively. (PL/Tcl does not currently offer any cursor functionality.) Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com> https://git.postgresql.org/pg/commitdiff/b3617cdfbba1b5381e9d1c6bc0839500e8eb7273
  • Revert "Move portal pinning from PL/pgSQL to SPI". This reverts commit b3617cdfbba1b5381e9d1c6bc0839500e8eb7273. This broke returning unnamed cursors from PL/pgSQL functions. Apparently, there are no test cases for this. https://git.postgresql.org/pg/commitdiff/b48b2f8793ef256d19274b4ef6ff587fd47ab553
  • Add tests for PL/pgSQL returning unnamed portals as refcursor. Existing tests only covered returning explicitly named portals as refcursor. The unnamed cursor case was recently broken without a test failing. https://git.postgresql.org/pg/commitdiff/511585417079b7d52211e09b20de0e0981b6eaa6
  • Use portal pinning in PL/Perl and PL/Python. PL/pgSQL "pins" internally generated portals so that user code cannot close them by guessing their names. Add this functionality to PL/Perl and PL/Python as well, preventing users from manually closing cursors created by spi_query and plpy.cursor, respectively. (PL/Tcl does not currently offer any cursor functionality.) https://git.postgresql.org/pg/commitdiff/70d6226e4fba26765877fc3c2ec6c468d3ff4084
  • Fix Latin spelling. "c.f." should be "cf.". https://git.postgresql.org/pg/commitdiff/9e945f862633882cae3183d465f321bd8dd591f9
  • Refactor subscription tests to use PostgresNode's wait_for_catchup. This was nearly the same code. Extend wait_for_catchup to allow waiting for pg_current_wal_lsn() and use that in the subscription tests. Also change one use in the pg_rewind tests to use this. Also remove some broken code in wait_for_catchup and wait_for_slot_catchup. The error message in case the waiting failed wanted to show the current LSN, but the way it was written never worked. So since nobody ever cared, just remove it. Reviewed-by: Michael Paquier <michael.paquier@gmail.com> https://git.postgresql.org/pg/commitdiff/bbd3363e128daec0e70952c1bb2f12ab1f6f1292

Andrew Dunstan pushed:

Álvaro Herrera pushed:

  • Change some bogus PageGetLSN calls to BufferGetLSNAtomic. As src/backend/access/transam/README says, PageGetLSN may only be called by processes holding either exclusive lock on buffer, or a shared lock on buffer plus buffer header lock. Therefore any place that only holds a shared buffer lock must use BufferGetLSNAtomic instead of PageGetLSN, which internally obtains buffer header lock prior to reading the LSN. A few callsites failed to comply with this rule. This was detected by running all tests under a new (not committed) assertion that verifies PageGetLSN locking contract. All but one of the callsites that failed the assertion are fixed by this patch. Remaining callsites were inspected manually and determined not to need any change. The exception (unfixed callsite) is in TestForOldSnapshot, which only has a Page argument, making it impossible to access the corresponding Buffer from it. Fixing that seems a much larger patch that will have to be done separately; and that's just as well, since it was only introduced in 9.6 and other bugs are much older. Some of these bugs are ancient; backpatch all the way back to 9.3. Authors: Jacob Champion, Asim Praveen, Ashwin Agrawal Reviewed-by: Michaël Paquier Discussion: https://postgr.es/m/CABAq_6GXgQDVu3u12mK9O5Xt5abBZWQ0V40LZCE+oUf95XyNFg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/272c2ab9fd0a604e3200030b1ea26fd464c44935
  • Remove hard-coded schema knowledge about pg_attribute from genbki.pl. Add the ability to label a column's default value in the catalog header, and implement this for pg_attribute. A new function in Catalog.pm is used to fill in a tuple with defaults. The build process will complain loudly if a catalog entry is incomplete, Commit 8137f2c3232 labeled variable length columns for the C preprocessor. Expose that label to genbki.pl so we can exclude those columns from schema macros in a general fashion. Also, format schema macro entries according to their types. This means slightly less code maintenance, but more importantly it's a proving ground for mechanisms intended to be used in later commits. While at it, I (Álvaro) couldn't resist making some changes in genbki.pl: rename some functions to actually indicate their purpose instead of actively misleading onlookers; and don't iterate on the whole of pg_type to find the entry for each catalog row, using a hash instead of an array. Author: John Naylor, some changes by Álvaro Herrera Discussion: https://postgr.es/m/CAJVSVGVJHwD8sfDfZW9TbCHWKf=C1YDRM-rF=2JenRU_y+VcFg@mail.gmail.com https://git.postgresql.org/pg/commitdiff/49c784ece766781250224a371be14af71e7eda93

Andres Freund pushed:

  • Expression evaluation based aggregate transition invocation. Previously aggregate transition and combination functions were invoked by special case code in nodeAgg.c, evaluating input and filters separately using the expression evaluation machinery. That turns out to not be great for performance for several reasons: - repeated expression evaluations have some cost - the transition functions invocations are poorly predicted, as commonly there are multiple aggregates in a query, resulting in the same call-stack invoking different functions. - filter and input computation had to be done separately - the special case code made it hard to implement JITing of the whole transition function invocation Address this by building one large expression that computes input, evaluates filters, and invokes transition functions. This leads to moderate speedups in queries bottlenecked by aggregate computations, and enables large speedups for similar cases once JITing is done. There's potential for further improvement: - It'd be nice if we could simplify the somewhat expensive aggstate->all_pergroups lookups. - right now there's still an advance_transition_function invocation in nodeAgg.c, leading to some code duplication. Author: Andres Freund Discussion: https://postgr.es/m/20170901064131.tazjxwus3k2w3ybh@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/69c3936a1499b772a749ae629fc59b2d72722332

Teodor Sigaev pushed:

  • Fix allowing of leading zero on exponents in pgbench test results. Commit bc7fa0c15c590ddf4872e426abd76c2634f22aca accidentally lost fixes of 0aa1d489ea756b96b6d5573692ae9cd5d143c2a5 commit. Thanks to Thomas Munro https://git.postgresql.org/pg/commitdiff/d16c2de6244f3b71c0c77a3d63905227fdc78428
  • Improve scripting language in pgbench. Added: - variable now might contain integer, double, boolean and null values - functions ln, exp - logical AND/OR/NOT - bitwise AND/OR/NOT/XOR - bit right/left shift - comparison operators - IS [NOT] (NULL|TRUE|FALSE) - conditional choice (in form of when/case/then) New operations and functions allow to implement more complicated test scenario. Author: Fabien Coelho with minor editorization by me Reviewed-By: Pavel Stehule, Jeevan Ladhe, me Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.10.1604030742390.31618@sto https://git.postgresql.org/pg/commitdiff/bc7fa0c15c590ddf4872e426abd76c2634f22aca
  • Fix behavior of ~> (cube, int) operator. ~> (cube, int) operator was especially designed for knn-gist search. However, it appears that knn-gist search can't work correctly with current behavior of this operator when dataset contains cubes of variable dimensionality. In this case, the same value of second operator argument can point to different dimension depending on dimensionality of particular cube. Such behavior is incompatible with gist indexing of cubes, and knn-gist doesn't work correctly for it. This patch changes behavior of ~> (cube, int) operator by introducing dimension numbering where value of second argument unambiguously identifies number of dimension. With new behavior, this operator can be correctly supported by knn-gist. Relevant changes to cube operator class are also included. Backpatch to v9.6 where operator was introduced. Since behavior of ~> (cube, int) operator is changed, depending entities must be refreshed after upgrade. Such as, expression indexes using this operator must be reindexed, materialized views must be rebuilt, stored procedures and client code must be revised to correctly use new behavior. That should be mentioned in release notes. Noticed by: Tomas Vondra Author: Alexander Korotkov Reviewed by: Tomas Vondra, Andrey Borodin Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com https://git.postgresql.org/pg/commitdiff/563a053bdd4b91c5e5560f4bf91220e562326f7d
  • Allow negative coordinate for ~> (cube, int) operator. ~> (cube, int) operator was especially designed for knn-gist search. However, knn-gist supports only ascending ordering of results. Nevertheless it would be useful to support descending ordering by ~> (cube, int) operator. We provide workaround for that: negative coordinate give us inversed value of corresponding cube bound. Therefore, knn search using negative coordinate gives us an effect of descending ordering by cube bound. Author: Alexander Korotkov Reviewed by: Tomas Vondra, Andrey Borodin Discussion: https://www.postgresql.org/message-id/flat/a9657f6a-b497-36ff-e56-482a2c7e3292@2ndquadrant.com https://git.postgresql.org/pg/commitdiff/f50c80dbb17efa39c169f6c510e9464486ff5edc

Michael Meskes pushed:

Correctifs en attente

Alexander Korotkov sent in another revision of a patch to implement incremental sort.

Shubham Barai sent in three more revisions of a patch to implement predicate locking for GiST indexes.

Haribabu Kommi sent in a patch to add a new libpq API, PQeffectiveconninfo, which is similar to PQconninfo. It provides the effectively used connection options in the current connection. An accompanying patch uses the API to add effective an conninfo column to pg_stat_wal_receiver.

Catalin Iacob sent in a patch to document huge_pages better.

Álvaro Herrera sent in three more revisions of a patch to implement local indexes on partitioned tables.

Michaël Paquier sent in a patch to clarify the hostaddrs part of the libpq documentation.

Masahiko Sawada sent in another revision of a patch to fix an bug in the slot error callback.

Haribabu Kommi sent in another revision of a patch to implement pluggable storage.

Peter Eisentraut sent in a patch to add a prokind column, replacing proisagg and proiswindow and update pg_proc.h with this change.

Andres Freund sent in a patch to implement grouping equality using expressions, a step towards JITing same.

Chapman Flack and Fabien COELHO traded patches to enable setting random seeds in pgbench.

Alexander Korotkov sent in two more revisions of a patch to implement 64-bit XIDs.

Ildar Musin and Fabien COELHO traded patches to implement a general purpose hashing function in pgbench.

David Rowley sent in another revision of a patch to implement runtime partition pruning.

Yuqi Gu sent in a patch to make crc32 more efficient on the ARM64 architecture.

Aleksandr Parfenov sent in another revision of a patch to make full text search configuration more flexible.

Fabien COELHO sent in a patch to fix an issue with pgbench on Windows.

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

Konstantin Knizhnik sent in another revision of a patch to improve non-injective functional indexes.

Fabien COELHO sent in a patch to fix a typo in a pgbench TAP test.

Konstantin Knizhnik sent in another revision of a patch to implement AS OF queries.

Nikita Glukhov sent in another revision of a patch to implement JSONPATH.

Nikita Glukhov sent in a patch to implement JSON functions per SQL:2016.

Nathan Bossart sent in another revision of a patch to add a NOWAIT option to VACUUM and add a parenthesized option syntax to ANALYZE.

Julian Markwort sent in another revision of a patch to enable pg_stat_statements to track poor plans.

Haribabu Kommi sent in two revisions of a patch to ensure that PQhost returns correct host details.

Fabien COELHO sent in another revision of a patch to add \if to pgbench.

Jeff Davis sent in another revision of a patch to implement range merge joins.

Daniel Gustafsson sent in two more revisions of a patch to use strcmp() instead of pg_strcasecmp() for identifier matching and avoid silently changing volatility in CREATE FUNCTION.

Amit Khandekar sent in another revision of a patch to make updates to partition keys that would have the effect of moving tuples to another partition Just Work™.

Nikita Glukhov sent in another revision of a patch to implement JSON_TABLE.

Etsuro Fujita sent in another revision of a patch to allow pushing more UPDATE quals to the PostgreSQL FDW.

Kyotaro HORIGUCHI sent in another revision of a patch to fix a WAL logging problem.

Kyotaro HORIGUCHI sent in another revision of a patch to implement asynchronous execution in general and in the PostgreSQL FDW in particular.

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

Konstantin Knizhnik sent in another revision of a patch to optimize secondary indexes.

Kyotaro HORIGUCHI sent in another revision of a patch to allow limiting the resources logical replication uses by adding a WAL relief valve for replication slots, a monitoring aid for max_replication_slots, TAP tests for the slot limiting feature, and document documentation for same.

Álvaro Herrera sent in another revision of a patch to implement unique indexes on partitioned tables.

Tsutomu Yamada sent in a patch to change estimate_path_cost_size in postgres_fdw to refer to foreignrel instead of baserel.

Tsutomu Yamada sent in a patch to add queryEnv to ExplainOneQuery_hook.

Stephen Frost sent in two more revisions of a patch to remove the redundant IndexTupleDSize macro.

Christian Rossow sent in a patch to implement bitwise logical operations implementation (xor / and / or / not) for bytea.

Amit Langote and David Rowley traded patches to speed up partition pruning.

Thomas Munro sent in another revision of a patch to add plan count and time to pg_stat_statements.

Vaishnavi Prabakaran sent in another revision of a patch to add batch/pipelining support to libpq.

Michaël Paquier sent in a patch to ensure that pg_get_functiondef remembers all GUC_LIST_INPUT GUCs.

Michaël Paquier sent in a patch to refactor the syscache routines to get attribute name, extend lookup routines for FDW and foreign server with NULL handling, refactor routines for subscription and publication lookups, and eliminate user-visible cache lookup errors for objaddr SQL functions.

Edmund Horner sent in another revision of a patch to add tab completion to SELECT in psql.

Amul Sul sent in another revision of a patch to see to it that when a tuple is being moved to another partition, the ip_blkid in the tuple header is set to InvalidBlockNumber and add isolation tests for same.

Konstantin Knizhnik sent in another revision of a patch to auto-prepare.

Artur Zakirov sent in a patch to fix a bug in to_timestamp() where it would, under some circumstances, ignore a '-' character it should have taken into account.

Anthony Bykov sent in another revision of a patch to implement JSONB transforms for PL/PythonU.

Etsuro Fujita sent in another revision of a patch to add an eqpath for foreignjoin.

Robert Haas sent in a patch to sort the epq path if needed.

Álvaro Herrera sent in another revision of a patch to implement foreign key arrays.

Tomas Vondra sent in another revision of a patch to implement multivariate histograms and MCV lists.

Anthony Bykov sent in another revision of a patch to implement transforms for JSONB for PL/Perl.

Ildar Musin sent in a patch to add random_zipfian function to the paragraph in pgbench documentation about random functions parameterization.

Curt Tilmes sent in a patch to find additional connection service files in a newly invented pg_service.conf.d directory.

John Naylor sent in two more revisions of a patch to refactor how bootstrap data is stored in source and handled.

Haribabu Kommi sent in a patch to define a previously undefined behavior when the PQHost() connect string contains both host and hostaddr types.