== PostgreSQL Weekly News - October 14, 2018 ==
| От | David Fetter |
|---|---|
| Тема | == PostgreSQL Weekly News - October 14, 2018 == |
| Дата | |
| Msg-id | 20181014230353.GA5763@fetter.org обсуждение исходный текст |
| Список | pgsql-announce |
== PostgreSQL Weekly News - October 14, 2018 == PostgreSQL 11 RC1 released. This is a great opportunity to test! If all goes well, 11 will be released October 18, 2018. https://www.postgresql.org/about/news/1893/ pgday.Seoul 2018 will be held in Seoul, South Korea on November 3, 2018 in Seoul. Korean language information is here: http://pgday.postgresql.kr/ == PostgreSQL Product News == Ajqvue Version 2.10, a java-based UI which supports PostgreSQL, released. http://ajqvue.com pg_partman 4.0.0, a management system for partitioned tables, released. https://github.com/pgpartman/pg_partman pgFormatter 3.2, a formatter/beautifier for SQL code, released. http://sqlformat.darold.net/ == PostgreSQL Jobs for October == http://archives.postgresql.org/pgsql-jobs/2018-10/ == PostgreSQL Local == PostgresConf South Africa 2018 will take place in Johannesburg on October 9, 2018 https://postgresconf.org/conferences/SouthAfrica2018 PostgreSQL Conference Europe 2018 will be held on October 23-26, 2018 at the Lisbon Marriott Hotel in Lisbon, Portugal. https://2018.pgconf.eu/ 2Q PGConf will be on December 4-5, 2018 in Chicago, IL. http://www.2qpgconf.com/ PGConf.ASIA 2018 will take place on December 10-12, 2018 in Akihabara, Tokyo, Japan. http://www.pgconf.asia/EN/2018/ pgDay Paris 2019 will be held in Paris, France on March 12, 2019 at 199bis rue Saint-Martin. The CfP is open until November 30, 2018. http://2019.pgday.paris/callforpapers/ PGConf APAC 2019 will be held in Singapore March 19-21, 2019. The CfP is open at http://2019.pgconfapac.org/cfp through November 16, 2018. http://2019.pgconfapac.org/ PGDay.IT 2019 will take place May 16th and May 17th in Bologna, Italy. The CfP is open at https://2019.pgday.it/en/blog/cfp and the Call for Workshops is at https://2019.pgday.it/en/blog/cfw until January 15, 2019. https://2019.pgday.it/en/ == 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 == Magnus Hagander pushed: - Fix speling error. Reported by Alexander Lakhin in bug #15423 https://git.postgresql.org/pg/commitdiff/a9da329be0bec586589cefc78da03ddb3fc13cbb Michaël Paquier pushed: - Improve two error messages related to foreign keys on partitioned tables. Error messages for creating a foreign key on a partitioned table using ONLY or NOT VALID were wrong in mentioning the objects they worked on. This commit adds on the way some regression tests missing for those cases. Author: Laurenz Albe Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/c11c05810a9ed65e9b2c817a9ef442275a32fe80.camel@cybertec.at https://git.postgresql.org/pg/commitdiff/9c2a970d1fa4d30dc41d30d0b2ad557f40510549 - Add pg_ls_archive_statusdir function. This function lists the contents of the WAL archive status directory, and is intended to be used by monitoring tools. Unlike pg_ls_dir(), access to it can be granted to non-superusers so that those monitoring tools can observe the principle of least privilege. Access is also given by default to members of pg_monitor. Author: Christoph Moench-Tegeder Reviewed-by: Aya Iwata Discussion: https://postgr.es/m/20180930205920.GA64534@elch.exwg.net https://git.postgresql.org/pg/commitdiff/c48101620151f78ee184e5f81766cbac347d9a11 - Add TAP tests for pg_verify_checksums All options available in the utility get coverage: - Tests with disabled page checksums. - Tests with enabled test checksums. - Emulation of corruption and broken checksums with a full scan and. single relfilenode scan. This patch has been contributed mainly by Michael Banck and Magnus Hagander with things presented on various threads, and I have gathered all the contents into a single patch. Author: Michael Banck, Magnus Hagander, Michael Paquier Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/20181005012645.GE1629@paquier.xyz https://git.postgresql.org/pg/commitdiff/b34e84f160a47d9070b304bfc1baf17596d71865 - Avoid duplicate XIDs at recovery when building initial snapshot. On a primary, sets of XLOG_RUNNING_XACTS records are generated on a periodic basis to allow recovery to build the initial state of transactions for a hot standby. The set of transaction IDs is created by scanning all the entries in ProcArray. However it happens that its logic never counted on the fact that two-phase transactions finishing to prepare can put ProcArray in a state where there are two entries with the same transaction ID, one for the initial transaction which gets cleared when prepare finishes, and a second, dummy, entry to track that the transaction is still running after prepare finishes. This way ensures a continuous presence of the transaction so as callers of for example TransactionIdIsInProgress() are always able to see it as alive. So, if a XLOG_RUNNING_XACTS takes a standby snapshot while a two-phase transaction finishes to prepare, the record can finish with duplicated XIDs, which is a state expected by design. If this record gets applied on a standby to initial its recovery state, then it would simply fail, so the odds of facing this failure are very low in practice. It would be tempting to change the generation of XLOG_RUNNING_XACTS so as duplicates are removed on the source, but this requires to hold on ProcArrayLock for longer and this would impact all workloads, particularly those using heavily two-phase transactions. XLOG_RUNNING_XACTS is also actually used only to initialize the standby state at recovery, so instead the solution is taken to discard duplicates when applying the initial snapshot. Diagnosed-by: Konstantin Knizhnik Author: Michael Paquier Discussion: https://postgr.es/m/0c96b653-4696-d4b4-6b5d-78143175d113@postgrespro.ru Backpatch-through: 9.3 https://git.postgresql.org/pg/commitdiff/1df21ddb19c6e764fc9378c900515a5d642ad820 Peter Eisentraut pushed: - Track procedure calls in pg_stat_user_functions. This was forgotten when procedures were implemented. Reported-by: Lukas Fittl <lukas@fittl.com> https://git.postgresql.org/pg/commitdiff/634b4b79cbc7638feb459a1b76eae7af47af4606 - Turn transaction_isolation into GUC enum. It was previously a string setting that was converted into an enum by custom code, but using the GUC enum facility seems much simpler and doesn't change any functionality, except that set transaction_isolation='default'; no longer works, but that was never documented and doesn't work with any other transaction characteristics. (Note that this is not the same as RESET or SET TO DEFAULT, which still work.) Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://www.postgresql.org/message-id/457db615-e84c-4838-310e-43841eb806e5@iki.fi https://git.postgresql.org/pg/commitdiff/f8c10f616fa5081999ac48a0b6621057db806851 - Test that event triggers work in functions and procedures. This ensures that we have coverage of all the ProcessUtilityContext variants. https://git.postgresql.org/pg/commitdiff/ae307861d89767991b71e97faa6e1812e5ab83f9 - Slightly correct context check for event triggers. The previous check for a "complete query" omitted the new PROCESS_UTILITY_QUERY_NONATOMIC value. This didn't actually make a difference in practice, because only CALL and SET from PL/pgSQL run in this state, but it's more correct to include it anyway. Discussion: https://www.postgresql.org/message-id/4566041d-2567-74d2-d135-19ff6a20fe51%402ndquadrant.com https://git.postgresql.org/pg/commitdiff/f82d4d666ff501382b92dfd80eaf1d459e6e84a3 Álvaro Herrera pushed: - Silence compiler warning in Assert(). gcc 6.3 does not whine about this mistake I made in 39808e8868c8 but evidently lots of other compilers do, according to Michael Paquier, Peter Eisentraut, Arthur Zakirov, Tomas Vondra. Discussion: too many to list https://git.postgresql.org/pg/commitdiff/eee01d606eb40f760799320e75d45c84022353d8 - Correct attach/detach logic for FKs in partitions. There was no code to handle foreign key constraints on partitioned tables in the case of ALTER TABLE DETACH; and if you happened to ATTACH a partition that already had an equivalent constraint, that one was ignored and a new constraint was created. Adding this to the fact that foreign key cloning reuses the constraint name on the partition instead of generating a new name (as it probably should, to cater to SQL standard rules about constraint naming within schemas), the result was a pretty poor user experience -- the most visible failure was that just detaching a partition and re-attaching it failed with an error such as ERROR: duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index" DETAIL: Key (conrelid, contypid, conname)=(26702, 0, test_result_asset_id_fkey) already exists. because it would try to create an identically-named constraint in the partition. To make matters worse, if you tried to drop the constraint in the now-independent partition, that would fail because the constraint was still seen as dependent on the constraint in its former parent partitioned table: ERROR: cannot drop inherited constraint "test_result_asset_id_fkey" of relation "test_result_cbsystem_0001_0050_monthly_2018_09" This fix attacks the problem from two angles: first, when the partition is detached, the constraint is also marked as independent, so the drop now works. Second, when the partition is re-attached, we scan existing constraints searching for one matching the FK in the parent, and if one exists, we link that one to the parent constraint. So we don't end up with a duplicate -- and better yet, we don't need to scan the referenced table to verify that the constraint holds. To implement this I made a small change to previously planner-only struct ForeignKeyCacheInfo to contain the constraint OID; also relcache now maintains the list of FKs for partitioned tables too. Backpatch to 11. Reported-by: Michael Vitale (bug #15425) Discussion: https://postgr.es/m/15425-2dbc9d2aa999f816@postgresql.org https://git.postgresql.org/pg/commitdiff/c7d43c4d8a5b7215ea0a32d95260188b5d3ae3f4 Tom Lane pushed: - Avoid O(N^2) cost in ExecFindRowMark(). If there are many ExecRowMark structs, we spent O(N^2) time in ExecFindRowMark during executor startup. Once upon a time this was not of great concern, but the addition of native partitioning has squeezed out enough other costs that this can become the dominant overhead in some use-cases for tables with many partitions. To fix, simply replace that List data structure with an array. This adds a little bit of cost to execCurrentOf(), but not much, and anyway that code path is neither of large importance nor very efficient now. If we ever decide it is a bottleneck, constructing a hash table for lookup-by-tableoid would likely be the thing to do. Per complaint from Amit Langote, though this is different from his fix proposal. Discussion: https://postgr.es/m/468c85d9-540e-66a2-1dde-fec2b741e688@lab.ntt.co.jp https://git.postgresql.org/pg/commitdiff/f9eb7c14b08d2cc5eda62ffaf37a356c05e89b93 - Improve snprintf.c's handling of NaN, Infinity, and minus zero. Up to now, float4out/float8out handled NaN and Infinity cases explicitly, and invoked psprintf only for ordinary float values. This was done because platform implementations of snprintf produce varying representations of these special cases. But now that we use snprintf.c always, it's better to give it the responsibility to produce a uniform representation of these cases, so that we have uniformity across the board not only in float4out/float8out. Hence, move that work into fmtfloat(). Also, teach fmtfloat() to recognize IEEE minus zero and handle it correctly. The previous coding worked only accidentally, and would fail for e.g. "%+f" format (it'd print "+-0.00000"). Now that we're using snprintf.c everywhere, it's not acceptable for it to do weird things in corner cases. (This incidentally avoids a portability problem we've seen on some really ancient platforms, that native sprintf does the wrong thing with minus zero.) Also, introduce a new entry point in snprintf.c to allow float[48]out to bypass the work of interpreting a well-known format spec, as well as bypassing the overhead of the psprintf layer. I modeled this API loosely on strfromd(). In my testing, this brings float[48]out back to approximately the same speed they had when using native snprintf, fixing one of the main performance issues caused by using snprintf.c. (There is some talk of more aggressive work to improve the speed of floating-point output conversion, but these changes seem to provide a better starting point for such work anyway.) Getting rid of the previous ad-hoc hack for Infinity/NaN in fmtfloat() allows removing <ctype.h> from snprintf.c's #includes. I also removed a few other #includes that I think are historical, though the buildfarm may expose that as wrong. Discussion: https://postgr.es/m/13178.1538794717@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6eb3eb577d76b3f58a98f78232af9e86624ce5eb - Advance transaction timestamp for intra-procedure transactions. Per discussion, this behavior seems less astonishing than not doing so. Peter Eisentraut and Tom Lane Discussion: https://postgr.es/m/20180920234040.GC29981@momjian.us https://git.postgresql.org/pg/commitdiff/82ff0cc91d9840d1c56ca1beed58bedfde3da9a3 - Fix omissions in snprintf.c's coverage of standard *printf functions. A warning on a NetBSD box revealed to me that pg_waldump/compat.c is using vprintf(), which snprintf.c did not provide coverage for. This is not good if we want to have uniform *printf behavior, and it's pretty silly to omit when it's a one-line function. I also noted that snprintf.c has pg_vsprintf() but for some reason it was not exposed to the outside world, creating another way in which code might accidentally invoke the platform *printf family. Let's just make sure that we replace all eight of the POSIX-standard printf family. Also, upgrade plperl.h and plpython.h to make sure that they do their undefine/redefine rain dance for all eight, not some random maybe-sufficient subset thereof. https://git.postgresql.org/pg/commitdiff/7767aadd94cd252a12fa00f6122ad4dd10455791 - Convert some long lists in configure.in to one-line-per-entry style. The idea here is that patches that add items to these lists will often be easier to rebase over other additions to the same lists, because they won't be trying to touch the very same line of configure.in. There will still be merge conflicts in the configure script, but that can be fixed just by re-running autoconf (or by leaving configure out of the submitted patch to begin with ...) Implementation note: use of m4_normalize() is necessary to get rid of the newlines, else incorrect shell syntax will be emitted. But with that hack, the generated configure script is identical to what it was before. Discussion: https://postgr.es/m/19344.1539050134@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/bfa6c5a0c974b14601b689efa4e52f6a372aee0c - Select appropriate PG_PRINTF_ATTRIBUTE for recent NetBSD. NetBSD-current generates a large number of warnings about "%m" not being appropriate to use with *printf functions. While that's true for their native printf, it's surely not true for snprintf.c, so I think they have misunderstood gcc's definition of the "gnu_printf" archetype. Nonetheless, choosing "__syslog__" instead silences the warnings; so teach configure about that. Since this is only a cosmetic warning issue (and anyway it depends on previous hacking to be self-consistent), no back-patch. Discussion: https://postgr.es/m/16785.1539046036@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/aed9fa0bd8973fd967724003e641a5b7054d6a80 - Remove no-longer-needed variant expected regression result files. numerology_1.out and float8-small-is-zero_1.out differ from their base files only in showing plain zero rather than minus zero for some results. I believe that in the wake of commit 6eb3eb577, we will print minus zero as such on all IEEE-float platforms (and non-IEEE floats are going to cause many more regression diffs than this, anyway). Hence we should be able to remove these and eliminate a bit of maintenance pain. Let's see if the buildfarm agrees. Discussion: https://postgr.es/m/29037.1539021687@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/6eb4378d53b58658c91e4a31d2511a15e6fbf088 - Make src/common/exec.c's error logging less ugly. This code used elog where it really ought to use ereport, mainly so that it can report a SQLSTATE different from ERRCODE_INTERNAL_ERROR. There were some other random deviations from typical error report practice too. In addition, we can make some cleanups that were impractical six months ago: * Use one variadic macro, instead of several with different numbers of arguments, reducing the temptation to force-fit messages into particular numbers of arguments; * Use %m, even in the frontend case, simplifying the code. Discussion: https://postgr.es/m/6025.1527351693@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/b6b297d20df9f738be20a450f80bade535819220 - Make float exponent output on Windows look the same as elsewhere. Windows, alone among our supported platforms, likes to emit three-digit exponent fields even when two digits would do. Adjust such results to look like the way everyone else does it. Eliminate a bunch of variant expected-output files that were needed only because of this quirk. Discussion: https://postgr.es/m/2934.1539122454@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/f1885386f6246ac7b6f8d3f0aef247988f48ee7a - Remove dead reference to ecpg resultmap file. I missed this in my prior commit because it doesn't matter in non-VPATH builds. Per buildfarm. https://git.postgresql.org/pg/commitdiff/24a2c436a5ce1912373a6c9561cbabd09495552d - Simplify use of AllocSetContextCreate() wrapper macro. We can allow this macro to accept either abbreviated or non-abbreviated allocation parameters by making use of __VA_ARGS__. As noted by Andres Freund, it's unlikely that any compiler would have __builtin_constant_p but not __VA_ARGS__, so this gives up little or no error checking, and it avoids a minor but annoying API break for extensions. With this change, there is no reason for anybody to call AllocSetContextCreateExtended directly, so in HEAD I renamed it to AllocSetContextCreateInternal. It's probably too late for an ABI break like that in 11, though. Discussion: https://postgr.es/m/20181012170355.bhxi273skjt6sag4@alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/13cd7209f794d9dff8084c9748a78a0a5bf0464a - Another round of portability hacking on ECPG regression tests. Removing the separate Windows expected-files in commit f1885386f turns out to have been too optimistic: on most (but not all!) of our Windows buildfarm members, the tests still print floats with three exponent digits, because they're invoking the native printf() not snprintf.c. But rather than put back the extra expected-files, let's hack the three tests in question so that they adjust float formatting the same way snprintf.c does. Discussion: https://postgr.es/m/18890.1539374107@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/240cd6bc8366c9848bc2511c623743326e5a187b - Make an editing pass over v11 release notes. Set the release date. Do a bunch of copy-editing and markup improvement, rearrange some stuff into what seemed a more sensible order, move some things that did not seem to be in the right section. https://git.postgresql.org/pg/commitdiff/5e9d7b226e04e11429ae644b5f7743503cd4d56b - Doc: copy-editing for CREATE INDEX reference page. Justin Pryzby, Jonathan S. Katz, and myself. Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com https://git.postgresql.org/pg/commitdiff/002791514328372b9682453f7692b032f9d0fb2f - Doc: further copy-editing for v11 release notes. Justin Pryzby, Jonathan S. Katz, and myself. Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com https://git.postgresql.org/pg/commitdiff/d3ef93f0ebc8bc831b436b1d473d7e80e73a3b1e - Doc: still further copy-editing for v11 release notes. Justin Pryzby and myself. Discussion: https://postgr.es/m/20181006134249.GD871@telsasoft.com https://git.postgresql.org/pg/commitdiff/8f850f2cad2df69a14fd1ad1b360cf004f17e8db - Clean up/tighten up coercibility checks in opr_sanity regression test. With the removal of the old abstime type, there are no longer any cases in this test where we need to use the weaker castcontext-ignoring form of binary coercibility check. (The other major source of such headaches, apparently-incompatible hash functions, is now hashvalidate()'s problem not this test script's problem.) Hence, just use binary_coercible() everywhere, and remove the comments explaining why we don't do so --- which were broken anyway by cda6a8d01. I left physically_coercible() in place but renamed it to better match what it's actually testing, and added some comments. Also, in test queries that have an assumption about the maximum number of function arguments they need to handle, add a clause to make them fail if someday there's a relevant function with more arguments. Otherwise we're likely not to notice that we need to extend the queries. Discussion: https://postgr.es/m/27637.1539388060@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/e9f42d529f990f94e1b7bdcec4a1111465c85326 - Use PlaceHolderVars within the quals of a FULL JOIN. This prevents failures in cases where we pull up a constant or var-free expression from a subquery and put it into a full join's qual. That can result in not recognizing the qual as containing a mergejoin-able or hashjoin-able condition. A PHV prevents the problem because it is still recognized as belonging to the side of the join the subquery is in. I'm not very sure about the net effect of this change on plan quality. In "typical" cases where the join keys are Vars, nothing changes. In an affected case, the PHV-wrapped expression is less likely to be seen as equal to PHV-less instances below the join, but more likely to be seen as equal to similar expressions above the join, so it may end up being a wash. In the one existing case where there's any visible change in a regression-test plan, it amounts to referencing a lower computation of a COALESCE result instead of recomputing it, which seems like a win. Given my uncertainty about that and the lack of field complaints, no back-patch, even though this is a very ancient problem. Discussion: https://postgr.es/m/32090.1539378124@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/7d4a10e260083bc571ea05592884084eabcc7afa - Make some subquery-using test cases a bit more robust. These test cases could be adversely affected by an upcoming change to allow pullup of FROM-less subqueries. Tweak them to ensure that they'll continue to test what they did before. Discussion: https://postgr.es/m/5395.1539275668@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/b403ea43e40aae3ebb03cf3844cf84b43ab34b8a Thomas Munro pushed: - Relax transactional restrictions on ALTER TYPE ... ADD VALUE (redux). Originally committed as 15bc038f (plus some follow-ups), this was reverted in 28e07270 due to a problem discovered in parallel workers. This new version corrects that problem by sending the list of uncommitted enum values to parallel workers. Here follows the original commit message describing the change: To prevent possibly breaking indexes on enum columns, we must keep uncommitted enum values from getting stored in tables, unless we can be sure that any such column is new in the current transaction. Formerly, we enforced this by disallowing ALTER TYPE ... ADD VALUE from being executed at all in a transaction block, unless the target enum type had been created in the current transaction. This patch removes that restriction, and instead insists that an uncommitted enum value can't be referenced unless it belongs to an enum type created in the same transaction as the value. Per discussion, this should be a bit less onerous. It does require each function that could possibly return a new enum value to SQL operations to check this restriction, but there aren't so many of those that this seems unmaintainable. Author: Andrew Dunstan and Tom Lane, with parallel query fix by Thomas Munro Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAEepm%3D0Ei7g6PaNTbcmAh9tCRahQrk%3Dr5ZWLD-jr7hXweYX3yg%40mail.gmail.com Discussion: https://postgr.es/m/4075.1459088427%40sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/212fab9926b2f0f04b0187568e7124b70e8deee5 Greg Stark pushed: - Add "B" suffix for bytes to docs. 6e7baa3227 and b06d8e58b5 added "B" as a valid suffix for GUC_UNIT_BYTES but neglected to add it to the docs. https://git.postgresql.org/pg/commitdiff/36e9d413a1d6928cd809d302d495fd6880a44b1e Andres Freund pushed: - Fix logical decoding error when system table w/ toast is repeatedly rewritten. Repeatedly rewriting a mapped catalog table with VACUUM FULL or CLUSTER could cause logical decoding to fail with: ERROR, "could not map filenode \"%s\" to relation OID" To trigger the problem the rewritten catalog had to have live tuples with toasted columns. The problem was triggered as during catalog table rewrites the heap_insert() check that prevents logical decoding information to be emitted for system catalogs, failed to treat the new heap's toast table as a system catalog (because the new heap is not recognized as a catalog table via RelationIsLogicallyLogged()). The relmapper, in contrast to the normal catalog contents, does not contain historical information. After a single rewrite of a mapped table the new relation is known to the relmapper, but if the table is rewritten twice before logical decoding occurs, the relfilenode cannot be mapped to a relation anymore. Which then leads us to error out. This only happens for toast tables, because the main table contents aren't re-inserted with heap_insert(). The fix is simple, add a new heap_insert() flag that prevents logical decoding information from being emitted, and accept during decoding that there might not be tuple data for toast tables. Unfortunately that does not fix pre-existing logical decoding errors. Doing so would require not throwing an error when a filenode cannot be mapped to a relation during decoding, and that seems too likely to hide bugs. If it's crucial to fix decoding for an existing slot, temporarily changing the ERROR in ReorderBufferCommit() to a WARNING appears to be the best fix. Author: Andres Freund Discussion: https://postgr.es/m/20180914021046.oi7dm4ra3ot2g2kt@alap3.anarazel.de Backpatch: 9.4-, where logical decoding was introduced https://git.postgresql.org/pg/commitdiff/e9edc1ba0be21278de8f04a068c2fb3504dc03fc - Force synchronous commit to be enabled for all test_decoding tests. Without that the tests fail when forced to be run against a cluster with synchronous_commit = off (as the WAL might not yet be flushed to disk by the point logical decoding gets called, and thus the expected output breaks). Most tests already do that, add it to a few newer tests. Author: Andres Freund https://git.postgresql.org/pg/commitdiff/ef493055b67d30393a71c59d6fcbc2bd406528c2 - Remove timetravel extension. The extension depended on old types which are about to be removed. As the code additionally was pretty crufty and didn't provide much in the way of functionality, removing the extension seems to be the best way forward. It's fairly trivial to write functionality in plpgsql that more than covers what timetravel did. Author: Andres Freund Discussion: https://postgr.es/m/20171213080506.cwjkpcz3bkk6yz2u@alap3.anarazel.de https://postgr.es/m/25615.1513115237@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/2d10defa7771931295ee804cf096fb9388472a7b - Move timeofday() implementation out of nabstime.c. nabstime.c is about to be removed, but timeofday() isn't related to the rest of the functionality therein, and some find it useful. Move to timestamp.c. Discussion: https://postgr.es/m/20181009192237.34wjp3nmw7oynmmr@alap3.anarazel.de https://postgr.es/m/20180928223240.kgwc4czzzekrpsid%40alap3.anarazel.de https://git.postgresql.org/pg/commitdiff/86896be60ef7ace74b7b6858588ec7fae030fefd - Remove deprecated abstime, reltime, tinterval datatypes. These types have been deprecated for a *long* time. Catversion bump, for obvious reasons. Author: Andres Freund Discussion: https://postgr.es/m/20181009192237.34wjp3nmw7oynmmr@alap3.anarazel.de https://postgr.es/m/20171213080506.cwjkpcz3bkk6yz2u@alap3.anarazel.de https://postgr.es/m/25615.1513115237@sss.pgh.pa.us https://git.postgresql.org/pg/commitdiff/cda6a8d01d391eab45c4b3e0043a1b2b31072f5f Alexander Korotkov pushed: - contrib/bloom documentation improvement. This commit documents rounding of "length" parameter and absence of support for unique indexes and NULLs searching. Backpatch to 9.6 where contrib/bloom was introduced. Discussion: https://postgr.es/m/CAF4Au4wPQQ7EHVSnzcLjsbY3oLSzVk6UemZLD1Sbmwysy3R61g%40mail.gmail.com Author: Oleg Bartunov with minor editorialization by me Backpatch-through: 9.6 https://git.postgresql.org/pg/commitdiff/98afb839059b2708ee4b541d0186581493a2713b - Add missed tag in bloom.sgml. Backpatch commits don't contain this error. https://git.postgresql.org/pg/commitdiff/981b64f840ba81adf47ea0c34694ea416134817e == Pending Patches == David Rowley sent in a patch to clarify and correct the documentation around runtime partition pruning. Alexander Kuzmenkov sent in another revision of a patch to remove some unneeded self-joins. Laurenz Albe sent in another revision of a patch to add pg_promote() to promote standby servers. Peter Eisentraut sent in another revision of a patch to implement chained transactions (T261 in the SQL standard). David Rowley sent in another revision of a patch to make run-time partition pruning more efficient. Andrew Dunstan sent in another revision of a patch to add an --exclude-database option to pg_dumpall. Haribabu Kommi sent in a patch to add a new API, setNewfilenode, and an API to create an INIT_FORKNUM file and a wrapper for same, table_create_init_fork. Kyotaro HORIGUCHI sent in another revision of a patch to ensure that anti-wraparound VACUUMs are always set as aggressive. Yang Xiao sent in a patch to ECPG to ensure that functions in dt_common correctly detect integer overflow. Yang Xiao sent in a patch to add an overflow test to numeric_exp(). Andres Freund sent in a patch to C99-ify FunctionCallInfoData and remove fmgr.[ch] duplication using macro magic. David Rowley sent in another revision of a patch to correct some comments and fix an out-dated README from run-time pruning. Daniel Gustafsson sent in two revisions of a patch to support using a custom socket directory during pg_upgrade. Thomas Munro sent in two more revisions of a patch to use pread()/pwrite() instead of lseek() + read()/write() where available. Thomas Munro sent in another revision of a patch to add kqueue(2) support for WaitEventSet. Julien Demoor sent in another revision of a patch to make it possible to collapse duplicate NOTIFYs. Thomas Munro sent in another revision of a patch to enable parallel query with SERIALIZABLE isolation and enable the read-only SERIALIZABLE optimization for Parallel query. Peter Eisentraut sent in another revision of a patch to ensure that when an error occurs during a pgbench run, pgbench exits with a non-zero exit code distinct from the one for errors during initialization and writes a message at the end reflecting the reason. Amit Khandekar sent in another revision of a patch to implement the TupleTableSlot abstraction. Thomas Munro sent in four more revisions of a patch to refactor random seed and start time initialization. Among other things, this ensures that background workers, including parallel workers, have distinct sequence numbers in random(). Daniel Gustafsson sent in another revision of a patch to send an optional message to the user when terminating or cancelling a backend. Thomas Munro sent in a patch to add a proc_die_hook to customize die() interrupt handling and remove the async-signal-unsafe bgworker_die() function. Richard Guo and Michaël Paquier traded patches to restore CurrentUserId only if 'prevUser' is valid. Amit Langote sent in another revision of a patch to add pg_partition_tree to display information about partitions. Haribabu Kommi sent in a patch to add the extension-specific details of all extensions present in the installation directory to pg_available_extensions. Dilip Kumar sent in a WIP patch to implement undoworker and transaction rollback using an UNDO log. Kyotaro HORIGUCHI sent in two more revisions of a patch to add a TAP test for the copy-truncation optimization, write a WAL entry for any empty nbtree index build, add infrastructure to the WAL-logging skip feature, and fix the WAL-skipping feature using same. Surafel Temesgen sent in a patch to add an optional WHEN to COPY ... FROM. Andrey Klychkov sent in a patch to change simple_heap_insert() to a macro, avoiding a function call in the process. Konstantin Knizhnik sent in another revision of a patch to optimize usage of secondary indexes. Sergei Kornilov sent in another revision of a patch to redo and expand the recovery.conf API. Tom Lane sent in a patch to Use PHVs within the join quals of a full join, even when it's the lowest nulling outer join. This is a partial fix for a performance problem with FULL JOINs. Nathan Bossart sent in a patch to refactor the maximum password length enforced by client utilities, add documentation regarding effective password length limits, and increase the accepted length of password messages to 8192. Fabien COELHO sent in another revision of a patch to clean up pgbench's doCustom. John Naylor sent in another revision of a patch to add a pg_language lookup and replace the /ad hoc/ format for conversion functions in the genbki infrastructure. John Naylor sent in two more revisions of a patch to avoid creating a free space map for small tables. Matheus de Oliveira sent in another revision of a patch to add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT. Tom Lane sent in a patch to get rid of empty jointrees.
В списке pgsql-announce по дате отправления: