== PostgreSQL Weekly News - February 14 2016 == Security Updates 9.5.1, 9.4.6, 9.3.11, 9.2.15, and 9.1.20, released. Upgrade ASAP! http://www.postgresql.org/about/news/1644/
== PostgreSQL Product News == pgpool-II 3.4.4, 3.3.8, 3.2.13, 3.1.16, and 3.0.20 released. pgpool-II is a connection pooler and replication system for PostgreSQL. http://pgpool.net/mediawiki/index.php/Downloads PL/Java 1.5.0-BETA1 is out, now with security policy changes. http://tada.github.io/pljava/ == PostgreSQL Jobs for February == http://archives.postgresql.org/pgsql-jobs/2016-02/ == PostgreSQL Local == Prague PostgreSQL Developer Day 2016 (P2D2 2016) is a two-day conference that will be held on February 17-18 2016 in Prague, Czech Republic. Czech language web site below: http://www.p2d2.cz/ The annual Indian PGday will be held in Bengaluru, Karnataka, India on February 26, 2016. http://pgday.in The first pan-Asian PostgreSQL conference will be held March 16-17, 2016 in Singapore. http://2016.pgday.asia/ Nordic PGDay 2016 is a one day one track conference which will be held in Helsinki, Finland, on March 17, 2016. Registration is still open. http://2016.nordicpgday.org/ The 8th PostgreSQL Session will be held on April 6th, 2016, in Lyon, France. The CfP is open until February 29, 2016 at call-for-paper <AT> postgresql-sessions <DOT> org. PGConf US 2016 will take place April 18-20, 2016 in NYC. http://www.pgconf.us/2016/ LinuxFest Northwest will take place April 23-24, 2016 at Bellingham Technical College in Bellingham, Washington, USA. The CfP is now open. http://www.linuxfestnorthwest.org/2016/present FOSS4G NA, will be held May 2-5, 2016 in Raleigh, North Carolina. The CfP is still open. https://2016.foss4g-na.org/cfp PGCon 2016 will be held May 17-21, 2016 in Ottawa. http://www.pgcon.org/ This year's Swiss PGDay will be held on June 24, 2016 at the University of Applied Sciences in Rapperswil (Switzerland). The CfP is open. http://www.pgday.ch/ "5432 ... Meet us!", will take place in Milan, Italy on June 28-29, 2016. The CfP is open until February 28th, 2016. http://5432meet.us/ == 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 Pacific time. Please send English language ones to da...@fetter.org, German language to p...@pgug.de, Italian language to p...@itpug.org. Spanish language to p...@arpug.com.ar. == Applied Patches == Heikki Linnakangas pushed: - Fix misspelled function name in comment. http://git.postgresql.org/pg/commitdiff/61ce1e8f154aefa97e9e5d5796f7b36c857efc74 Magnus Hagander pushed: - Fix typos in comments Author: Michael Paquier http://git.postgresql.org/pg/commitdiff/e51ab85cd95855d541311f204e1e7db2c40301f7 - Fix typo in comment http://git.postgresql.org/pg/commitdiff/23f3cc36ed8188b0b8bf22daa4bb5b47d216c15d Michael Meskes pushed: - Make sure ecpg header files do not have a comment lasting several lines, one of which is a preprocessor directive. This leads ecpg to incorrectly parse the comment as nested. http://git.postgresql.org/pg/commitdiff/7a58d19b0c80300e7974620d336d5f90fe2d0087 Fujii Masao pushed: - Various fixes to "ALTER ... SET/RESET" tab completions. Add: ALTER SYSTEM SET/RESET ... -> GUC variables, ALTER TABLE ... SET WITH -> OIDS, ALTER DATABASE/FUNCTION/ROLE/USER ... SET/RESET -> GUC variables, ALTER DATABASE/FUNCTION/ROLE/USER ... SET ... -> FROM CURRENT/TO, ALTER DATABASE/FUNCTION/ROLE/USER ... SET ... TO/= -> possible values, Author: Fujii Masao. Reviewed-by: Michael Paquier, Masahiko Sawada http://git.postgresql.org/pg/commitdiff/89611c4dfa67630f7dcc25881c17cbd1b2e24ea1 - Make GIN regression test stable. Commit 7f46eaf added the regression test which checks that gin_clean_pending_list() cleans up the GIN pending list and returns >0. This usually works fine. But if autovacuum comes along and cleans the list before gin_clean_pending_list() starts, the function may return 0, and then the regression test may fail. To fix the problem, this commit disables autovacuum on the target index of gin_clean_pending_list() by setting autovacuum_enabled reloption to off when creating the table. Also this commit sets gin_pending_list_limit reloption to 4MB on the target index. Otherwise when running "make installcheck" with small gin_pending_list_limit GUC, insertions of data may trigger the cleanup of pending list before gin_clean_pending_list() starts and the function may return 0. This could cause the regression test to fail. Per buildfarm member spoonbill. Reported-By: Tom Lane http://git.postgresql.org/pg/commitdiff/f8a1c1d5a30003c9c24b00870d5a0f02f1c81e65 Robert Haas pushed: - pgbench: Install guards against obscure overflow conditions. Dividing INT_MIN by -1 or taking INT_MIN modulo -1 can sometimes cause floating-point exceptions or otherwise misbehave. Fabien Coelho and Michael Paquier http://git.postgresql.org/pg/commitdiff/64f5edca2401f6c2f23564da9dd52e92d08b3a20 - Make all built-in lwlock tranche IDs fixed. This makes the values more stable, which seems like a good thing for anybody who needs to look at at them. Alexander Korotkov and Amit Kapila http://git.postgresql.org/pg/commitdiff/7191ce8bea0cb110a28faef178efa92bf456e030 - postgres_fdw: Allow fetch_size to be set per-table or per-server. The default fetch size of 100 rows might not be right in every environment, so allow users to configure it. Corey Huinker, reviewed by Kyotaro Horiguchi, Andres Freund, and me. http://git.postgresql.org/pg/commitdiff/dc203dc3ac40a4b02b92fb827848a547d2957153 - Remove CustomPath's TextOutCustomPath method. You can't really do anything useful with this in the form it currently exists; among other problems, there's no way to reread whatever information might be produced when the path is output. Work is underway to replace this with a more useful and more general system of extensible nodes, but let's start by getting rid of this bit. Extracted from a larger patch by KaiGai Kohei. http://git.postgresql.org/pg/commitdiff/f2305d40ec20e63f781983d103d819ad2b6c0faf - Code review for commit dc203dc3ac40a4b02b92fb827848a547d2957153. Remove duplicate assignment. This part by Ashutosh Bapat. Remove now-obsolete comment. This part by me, although the pending join pushdown patch does something similar, and for the same reason: there's no reason to keep two lists of the things in the fdw_private structure that have to be kept in sync with each other. http://git.postgresql.org/pg/commitdiff/52b63649fc5ff5d86227b8905e1c79cd9ceddf4c - Allow parallel custom and foreign scans. This patch doesn't put the new infrastructure to use anywhere, and indeed it's not clear how it could ever be used for something like postgres_fdw which has to send an SQL query and wait for a reply, but there might be FDWs or custom scan providers that are CPU-bound, so let's give them a way to join club parallel. KaiGai Kohei, reviewed by me. http://git.postgresql.org/pg/commitdiff/69d34408e5e7adcef8ef2f4e9c4f2919637e9a06 - Extend sortsupport for text to more opclasses. Have varlena.c expose an interface that allows the char(n), bytea, and bpchar types to piggyback on a now-generalized SortSupport for text. This pushes a little more knowledge of the bpchar/char(n) type into varlena.c than might be preferred, but that seems like the approach that creates least friction. Also speed things up for index builds that use text_pattern_ops or varchar_pattern_ops. This patch does quite a bit of renaming, but it seems likely to be worth it, so as to avoid future confusion about the fact that this code is now more generally used than the old names might have suggested. Peter Geoghegan, reviewed by Álvaro Herrera and Andreas Karlsson, with small tweaks by me. http://git.postgresql.org/pg/commitdiff/b47b4dbf683f13e6ef09fa0d93aa6e84f3d00819 - Change the way that LWLocks for extensions are allocated. The previous RequestAddinLWLocks() method had several disadvantages. First, the locks would be in the main tranche; we've recently decided that it's useful for LWLocks used for separate purposes to have separate tranche IDs. Second, there wasn't any correlation between what code called RequestAddinLWLocks() and what code called LWLockAssign(); when multiple modules are in use, it could become quite difficult to troubleshoot problems where LWLockAssign() ran out of locks. To fix, create a concept of named LWLock tranches which can be used either by extension or by core code. Amit Kapila and Robert Haas http://git.postgresql.org/pg/commitdiff/c1772ad9225641c921545b35c84ee478c326b95e - Add some additional core functions to support join pushdown for FDWs. GetExistingLocalJoinPath() is useful for handling EvalPlanQual rechecks properly, and GetUserMappingById() is needed to make sure you're using the right credentials. Shigeru Hanada, Etsuro Fujita, Ashutosh Bapat, Robert Haas http://git.postgresql.org/pg/commitdiff/a104a017fc5f67ff5d9c374cd831ac3948a874c2 - When modifying a foreign table, initialize tableoid field properly. Failure to do this can cause AFTER ROW triggers or RETURNING expressions that reference this field to misbehave. Etsuro Fujita, reviewed by Thom Brown http://git.postgresql.org/pg/commitdiff/9418d79a7664e75a2824adfc78b859b4d0f77962 - postgres_fdw: Avoid possible misbehavior when RETURNING tableoid column only. deparseReturningList ended up adding up RETURNING NULL to the code, but code elsewhere saw an empty list of attributes and concluded that it should not expect tuples from the remote side. Etsuro Fujita and Robert Haas, reviewed by Thom Brown http://git.postgresql.org/pg/commitdiff/37c84570b1e32aef886c9b546e0dd4a128cb7492 - postgres_fdw: pgindent run. In preparation for upcoming commits. http://git.postgresql.org/pg/commitdiff/d0cd7bda97a626049aa7d247374909c52399c413 - Fix typo. Amit Kapila http://git.postgresql.org/pg/commitdiff/78bea62ab0b16a0c7aaa1e460064c32f9f35041d - Fix small goof in comment. Peter Geoghegan http://git.postgresql.org/pg/commitdiff/63f39b9148319c2e399dd827941b4d579b79f18b - Remove parallel-safety check from GetExistingLocalJoinPath. Commit a104a017fc5f67ff5d9c374cd831ac3948a874c2 has this check because I added it to the submitted patch before commit, but that was entirely wrongheaded, as explained to me by Ashutosh Bapat, who also wrote this patch. http://git.postgresql.org/pg/commitdiff/e0e7b8fa22539a81cc390f8ec57d6b52391b1335 - Fix typo in comment. Michael Paquier http://git.postgresql.org/pg/commitdiff/e98fd7860773698eaaf6332decc364bb31bca677 - Introduce group locking to prevent parallel processes from deadlocking. For locking purposes, we now regard heavyweight locks as mutually non-conflicting between cooperating parallel processes. There are some possible pitfalls to this approach that are not to be taken lightly, but it works OK for now and can be changed later if we find a better approach. Without this, it's very easy for parallel queries to silently self-deadlock if the user backend holds strong relation locks. Robert Haas, with help from Amit Kapila. Thanks to Noah Misch and Andres Freund for extensive discussion of possible issues with this approach. http://git.postgresql.org/pg/commitdiff/a1c1af2a1f6099c039f145c1edb52257f315be51 - Introduce a new GUC force_parallel_mode for testing purposes. When force_parallel_mode = true, we enable the parallel mode restrictions for all queries for which this is believed to be safe. For the subset of those queries believed to be safe to run entirely within a worker, we spin up a worker and run the query there instead of running it in the original process. When force_parallel_mode = regress, make additional changes to allow the regression tests to run cleanly even though parallel workers have been injected under the hood. Taken together, this facilitates both better user testing and better regression testing of the parallelism code. Robert Haas, with help from Amit Kapila and Rushabh Lathia. http://git.postgresql.org/pg/commitdiff/7c944bd903392829608a9fba5b0e68c4fe89abf8 - Fix parallel-safety markings for pg_upgrade functions. These establish backend-local state which will not be copied to parallel workers, so they must be marked parallel-restricted, not parallel-safe. http://git.postgresql.org/pg/commitdiff/d89f06f0482458d4b76e3be67ea428fec2a0aeb6 - postgres_fdw: Push down joins to remote servers. If we've got a relatively straightforward join between two tables, this pushes that join down to the remote server instead of fetching the rows for each table and performing the join locally. Some cases are not handled yet, such as SEMI and ANTI joins. Also, we don't yet attempt to create presorted join paths or parameterized join paths even though these options do get tried for a base relation scan. Nevertheless, this seems likely to be a very significant win in many practical cases. Shigeru Hanada and Ashutosh Bapat, reviewed by Robert Haas, with additional review at various points by Tom Lane, Etsuro Fujita, KaiGai Kohei, and Jeevan Chalke. http://git.postgresql.org/pg/commitdiff/e4106b2528727c4b48639c0e12bf2f70a766b910 - postgres_fdw: Remove unstable regression test. Per Tom Lane and the buildfarm. http://git.postgresql.org/pg/commitdiff/bb4df42e6a394ce77801b6952b6dc8b43d91fea7 - postgres_fdw: Remove unnecessary variable. It causes warnings in non-Assert-enabled builds. Per report from Jeff Janes. http://git.postgresql.org/pg/commitdiff/019e78813760e664a85f505b5953d362a2b468cc - Code cleanup in the wake of recent LWLock refactoring. As of commit c1772ad9225641c921545b35c84ee478c326b95e, there's no longer any way of requesting additional LWLocks in the main tranche, so we don't need NumLWLocks() or LWLockAssign() any more. Also, some of the allocation counters that we had previously aren't needed any more either. Amit Kapila http://git.postgresql.org/pg/commitdiff/79a7ff0fe56ac9d782b0734ebb0e7a5299015e58 - Specify permutations for isolation tests with "invalid" permutations. This is a necessary prerequisite for forthcoming changes to allow deadlock scenarios to be tested by the isolation tester. It is also a good idea on general principle, since these scenarios add no useful test coverage not provided by other scenarios, but do to take time to execute. http://git.postgresql.org/pg/commitdiff/c9882c60f44cf5d0b37411535175a5c154fdad0e - Modify the isolation tester so that multiple sessions can wait. This allows testing of deadlock scenarios. Scenarios that would previously have been considered invalid are now simply taken as a scenario in which more than one backend will wait. http://git.postgresql.org/pg/commitdiff/38f8bdcac4982215beb9f65a19debecaf22fd470 - Rename PGPROC fields related to group XID clearing again. Commit 0e141c0fbb211bdd23783afa731e3eef95c9ad7a introduced a new facility to reduce ProcArrayLock contention by clearing several XIDs from the ProcArray under a single lock acquisition. The names initially chosen were deemed not to be very good choices, so commit 4aec49899e5782247e134f94ce1c6ee926f88e1c renamed them. But now it seems like we still didn't get it right. A pending patch wants to add similar infrastructure for batching CLOG updates, so the names need to be clear enough to allow a new set of structure members with a related purpose. Amit Kapila http://git.postgresql.org/pg/commitdiff/a455878d99561d4b199915ed7a7fb02f5e621710 - Add some isolation tests for deadlock detection and resolution. Previously, we had no test coverage for the deadlock detector. http://git.postgresql.org/pg/commitdiff/4c9864b9b4d87d02f07f40bb27976da737afdcab - Use separate lwlock tranches for buffer, lock, and predicate lock managers. This finishes the work - spread across many commits over the last several months - of putting each type of lock other than the named individual locks into a separate tranche. Amit Kapila http://git.postgresql.org/pg/commitdiff/c319991bcad02a2e99ddac3f42762b0f6fa8d52a - Make builtin lwlock tranche names consistent. Previously, we had a mix of styles. Amit Kapila http://git.postgresql.org/pg/commitdiff/63461a63f94a333eae272be3d44ae1602cda75cb - Introduce extensible node types. An extensible node is always tagged T_Extensible, but the extnodename field identifies it more specifically; it may also include arbitrary private data. Extensible nodes can be copied, tested for equality, serialized, and deserialized, but the core system doesn't know anything about them otherwise. Some extensions may find it useful to include these nodes in fdw_private or custom_private lists in lieu of arm-wrestling their data into a format that the core code can understand. Along the way, so as not to burden the authors of such extensible node types too much, expose the functions for writing serialized tokens, and for serializing and deserializing bitmapsets. KaiGai Kohei, per a design suggested by me. Reviewed by Andres Freund and by me, and further edited by me. http://git.postgresql.org/pg/commitdiff/bcac23de73b89b001fbc628d84471a392e928d1c Álvaro Herrera pushed: - pgbench: allow per-script statistics Provide per-script statistical info (count of transactions executed under that script, average latency for the whole script) after a multi-script run, adding an intermediate level of detail to existing global stats and per-command stats. Author: Fabien Coelho Reviewer: Michaël Paquier, Álvaro Herrera http://git.postgresql.org/pg/commitdiff/1d0c3b3f8a98b0ed9515ff0a3868266c3bfb5d38 - Don't test for system columns on join relations. create_foreignscan_plan needs to know whether any system columns are requested from a relation (this flag is needed by ForeignNext during execution). However, for join relations this is a pointless test, because it's not possible to request system columns from them, so remove the check. Author: Etsuro Fujita. Discussion: http://www.postgresql.org/message-id/56aa0fc5.9000...@lab.ntt.co.jp. Reviewed-by: David Rowley, Robert Haas. http://git.postgresql.org/pg/commitdiff/3cb5867b7d346eff4abcb69ca182ba658d5faecc - pgbench: fix segfault with empty sql file. Commit 1d0c3b3f8a introduced a bug that causes pgbench to crash if an empty script file is specified. Fix it by rejecting such files at startup, which is the historical and intended behavior. Reported-By: Jeff Janes. Discussion: https://www.postgresql.org/message-id/CAMkU=1zxKUbLPOt9hQWFp14pTc=v0cgo2gqbbn2gsk2pu+8...@mail.gmail.com http://git.postgresql.org/pg/commitdiff/db94419ffd6833da27176f6cca843483b4515065 - pgbench: cleanup use of a "logfile" parameter. There is no reason to have the per-thread logfile file pointer as a separate parameter in various functions: it's much simpler to put it in the per-thread state struct instead, which is already being passed to all functions that need the log file anyway. Change the callsites in which it was used as a boolean to test whether logging is active, so that they use the use_log global variable instead. No backpatch, even though this exists since commit a887c486d5df of March 2010, because this is just for cleanliness' sake and the surrounding code has been modified a lot recently anyway. http://git.postgresql.org/pg/commitdiff/34f13cc48432fb0a70bd76116347a758b7a0bc63 Teodor Sigaev pushed: - Fix lossy KNN GiST when ordering operator returns non-float8 value. KNN GiST with recheck flag should return to executor the same type as ordering operator, GiST detects this type by looking to return type of function which implements ordering operator. But occasionally detecting code works after replacing ordering operator function to distance support function. Distance support function always returns float8, so, detecting code get float8 instead of actual return type of ordering operator. Built-in opclasses don't have ordering operator which doesn't return non-float8 value, so, tests are impossible here, at least now. Backpatch to 9.5 where lozzy KNN was introduced. Author: Alexander Korotkov Report by: Artur Zakirov http://git.postgresql.org/pg/commitdiff/f25d07d99f4acf136baed4ef29ea97faad7337db - Improve error reporting in format() Clarify invalid format conversion type error message and add hint. Author: Jim Nasby http://git.postgresql.org/pg/commitdiff/07d25a964b2fb78169a4a34c6f6893736f69903a Tom Lane pushed: - Fix pg_description entries for jsonb_to_record() and jsonb_to_recordset(). All the other jsonb function descriptions refer to the arguments as being "jsonb", but these two said "json". Make it consistent. Per bug #13905 from Petru Florin Mihancea. No catversion bump --- we can't force one in the back branches, and this isn't very critical anyway. http://git.postgresql.org/pg/commitdiff/a4627e8fd479ff74fffdd49ad07636b79751be45 - Remove unnecessary "implementation of FOO operator" DESCR() entries. Apparently at least one committer hasn't gotten the word that these do not need to be maintained by hand, since initdb will create them automatically. Noted while fixing bug #13905. No catversion bump since the post-initdb state is exactly the same either way. I don't see a need for back-patch, either. http://git.postgresql.org/pg/commitdiff/2ad83fff221eec2cc76f8823b0043763d0dfe0c3 - Remove printQueryOpt.quote field. This field was included in the original definition of the printQueryOpt struct in commit a45195a191eec367, but it was not used anywhere in that commit, nor since then. Spotted by Dickson S. Guedes. http://git.postgresql.org/pg/commitdiff/2808a2e0f3e7dd98f5dc3041183fd5f389e0a8e1 - Fix IsValidJsonNumber() to notice trailing non-alphanumeric garbage. Commit e09996ff8dee3f70 was one brick shy of a load: it didn't insist that the detected JSON number be the whole of the supplied string. This allowed inputs such as "2016-01-01" to be misdetected as valid JSON numbers. Per bug #13906 from Dmitry Ryabov. In passing, be more wary of zero-length input (I'm not sure this can happen given current callers, but better safe than sorry), and do some minor cosmetic cleanup. http://git.postgresql.org/pg/commitdiff/e6ecc93a1747624c4d33fa48d8a2d77319f3400f - Make hstore_to_jsonb_loose match hstore_to_json_loose on what's a number. Commit e09996ff8dee3f70 removed some ad-hoc code in hstore_to_json_loose that determined whether an hstore value string looked like a number, in favor of calling the JSON parser's is-it-a-number code. However, it neglected the fact that the exact same code appeared in hstore_to_jsonb_loose. This is not a bug, exactly, because the requirements on the two functions are not the same: hstore_to_json_loose must accept only syntactically legal JSON numbers as numbers, or it will produce invalid JSON output, as per bug #12070 which spawned the prior commit. But hstore_to_jsonb_loose could accept anything that numeric_in will eat, other than Inf and NaN. Nonetheless it seems surprising and arbitrary that the two functions don't use the same rules for what is a number versus what is a string; especially since they did use the same rules before the aforesaid commit. For one thing, that means that doing hstore_to_json_loose and then casting to jsonb can produce results different from doing just hstore_to_jsonb_loose. Hence, change hstore_to_jsonb_loose's logic to match hstore_to_json_loose, ie, hstore values are treated as numbers when they match the JSON syntax for numbers. No back-patch, since this is more in the nature of a definitional change than a bug fix. http://git.postgresql.org/pg/commitdiff/41d2c081ce659f40dec3eb9efc647082aa775eb4 - Add hstore_to_jsonb() and hstore_to_jsonb_loose() to hstore documentation. These were never documented anywhere user-visible. Tut tut. http://git.postgresql.org/pg/commitdiff/24a26c9f5448b24943df4c9bcf154bfd9f8197a6 - In pg_dump, ensure that view triggers are processed after view rules. If a view is split into CREATE TABLE + CREATE RULE to break a circular dependency, then any triggers on the view must be dumped/reloaded after the CREATE RULE; else the backend may reject the CREATE TRIGGER because it's the wrong type of trigger for a plain table. This works all right in plain dump/restore because of pg_dump's sorting heuristic that places triggers after rules. However, when using parallel restore, the ordering must be enforced by a dependency --- and we didn't have one. Fixing this is a mere matter of adding an addObjectDependency() call, except that we need to be able to find all the triggers belonging to the view relation, and there was no easy way to do that. Add fields to pg_dump's TableInfo struct to remember where the associated TriggerInfo struct(s) are. Per bug report from Dennis Kögel. The failure can be exhibited at least as far back as 9.1, so back-patch to all supported branches. http://git.postgresql.org/pg/commitdiff/0ed707e9b7e90891d0eda91b353edf3a69c4b7c4 - Simplify syntax diagram for REINDEX. Since there currently is only one possible parenthesized option, namely VERBOSE, it's a bit pointless to show it with "{ } [, ... ]". The curly braces are useless and therefore confusing, as seen in a recent question from Karsten Hilbert. Remove the extra decoration for the time being; we can put it back when and if REINDEX grows some more options. http://git.postgresql.org/pg/commitdiff/5ef244a28266ce8e5666b23baed33a4c238542ff - Add num_nulls() and num_nonnulls() to count NULL arguments. An example use-case is "CHECK(num_nonnulls(a,b,c) = 1)" to assert that exactly one of a,b,c isn't NULL. The functions are variadic, so they can also be pressed into service to count the number of null or nonnull elements in an array. Marko Tiikkaja, reviewed by Pavel Stehule http://git.postgresql.org/pg/commitdiff/6819514fca22f8554edcab6e4d0402b0221f03bb - Update time zone data files to tzdata release 2016a. DST law changes in Cayman Islands, Metlakatla, Trans-Baikal Territory (Zabaykalsky Krai). Historical corrections for Pakistan. http://git.postgresql.org/pg/commitdiff/a73311e5256b57a59677083e71b5bf93e583cc05 - First-draft release notes for 9.4.6. As usual, the release notes for other branches will be made by cutting these down, but put them up for community review first. http://git.postgresql.org/pg/commitdiff/7008e70d105b572821406744ce080771b74c06ab - Add missing "static" qualifier. Per buildfarm member pademelon. http://git.postgresql.org/pg/commitdiff/392998bc58a985ea978c94c23594eb214d04c744 - Improve HJDEBUG code a bit. Commit 30d7ae3c76d2de144232ae6ab328ca86b70e72c3 introduced an HJDEBUG stanza that probably didn't compile at the time, and definitely doesn't compile now, because it refers to a nonexistent variable. It doesn't seem terribly useful anyway, so just get rid of it. While I'm fooling with it, use %z modifier instead of the obsolete hack of casting size_t to unsigned long, and include the HashJoinTable's address in each printout so that it's possible to distinguish the activities of multiple hashjoins occurring in one query. Noted while trying to use HJDEBUG to investigate bug #13908. Back-patch to 9.5, because code that doesn't compile is certainly not very helpful. http://git.postgresql.org/pg/commitdiff/be11f8400d7d99e8ae6602f3175e04b4f0c99376 - Fix comment block trashed by pgindent. Looks like I put the protective dashes in the wrong place in f4e4b32743. http://git.postgresql.org/pg/commitdiff/b921aeb1676f128f2c41ddc40d3887964ea9eae9 - Improve speed of timestamp/time/date output functions. It seems that sprintf(), at least in glibc's version, is unreasonably slow compared to hand-rolled code for printing integers. Replacing most uses of sprintf() in the datetime.c output functions with special-purpose code turns out to give more than a 2X speedup in COPY of a table with a single timestamp column; which is pretty impressive considering all the other logic in that code path. David Rowley and Andres Freund, reviewed by Peter Geoghegan and myself http://git.postgresql.org/pg/commitdiff/aa2387e2fd532954e88dfd8546ab894b9305123d - ExecHashRemoveNextSkewBucket must physically copy tuples to main hashtable. Commit 45f6240a8fa9d355 added an assumption in ExecHashIncreaseNumBatches and ExecHashIncreaseNumBuckets that they could find all tuples in the main hash table by iterating over the "dense storage" introduced by that patch. However, ExecHashRemoveNextSkewBucket continued its old practice of simply re-linking deleted skew tuples into the main table's hashchains. Hence, such tuples got lost during any subsequent increase in nbatch or nbuckets, and would never get joined, as reported in bug #13908 from Seth P. I (tgl) think that the aforesaid commit has got multiple design issues and should be reworked rather completely; but there is no time for that right now, so band-aid the problem by making ExecHashRemoveNextSkewBucket physically copy deleted skew tuples into the "dense storage" arena. The added test case is able to exhibit the problem by means of fooling the planner with a WHERE condition that it will underestimate the selectivity of, causing the initial nbatch estimate to be too small. Tomas Vondra and Tom Lane. Thanks to David Johnston for initial investigation into the bug report. http://git.postgresql.org/pg/commitdiff/f867ce5518202a4e625dc41b7036fec47ee0e09e - Release notes for 9.5.1, 9.4.6, 9.3.11, 9.2.15, 9.1.20. http://git.postgresql.org/pg/commitdiff/1d76c9725087121bfa008f875450570a5c46241f - Fix deparsing of ON CONFLICT arbiter WHERE clauses. The parser doesn't allow qualification of column names appearing in these clauses, but ruleutils.c would sometimes qualify them, leading to dump/reload failures. Per bug #13891 from Onder Kalaci. (In passing, make stanzas in ruleutils.c that save/restore varprefix more consistent.) Peter Geoghegan http://git.postgresql.org/pg/commitdiff/cc2ca9319a5dbe89ea47d87944650e65e3bb4ce8 - Improve documentation about PRIMARY KEY constraints. Get rid of the false implication that PRIMARY KEY is exactly equivalent to UNIQUE + NOT NULL. That was more-or-less true at one time in our implementation, but the standard doesn't say that, and we've grown various features (many of them required by spec) that treat a pkey differently from less-formal constraints. Per recent discussion on pgsql-general. I failed to resist the temptation to do some other wordsmithing in the same area. http://git.postgresql.org/pg/commitdiff/c477e84fe2471cb675234fce75cd6bb4bc2cf481 - Use %u not %d to print OIDs. Oversight in commit 96198d94c. Etsuro Fujita http://git.postgresql.org/pg/commitdiff/63828969c822449744e63b76bff993ccd1d3245e - Re-pgindent varlena.c. Just to make sure previous commit worked ... http://git.postgresql.org/pg/commitdiff/0231f838565d2921a0960407c4240237ba1d56ae - Rename typedef "string" to "VarString". Since pgindent treats typedef names as global, the original coding of b47b4dbf683f13e6 would have had rather nasty effects on the formatting of other files in which "string" is used as a variable or field name. Use a less generic name for this typedef, and rename some other identifiers to match. Peter Geoghegan, per gripe from me http://git.postgresql.org/pg/commitdiff/58e797216ff52c0656d3c343d0732a2530cafb71 - Temporarily make pg_ctl and server shutdown a whole lot chattier. This is a quick hack, due to be reverted when its purpose has been served, to try to gather information about why some of the buildfarm critters regularly fail with "postmaster does not shut down" complaints. Maybe they are just really overloaded, but maybe something else is going on. Hence, instrument pg_ctl to print the current time when it starts waiting for postmaster shutdown and when it gives up, and add a lot of logging of the current time in the server's checkpoint and shutdown code paths. No attempt has been made to make this pretty. I'm not even totally sure if it will build on Windows, but we'll soon find out. http://git.postgresql.org/pg/commitdiff/3971f64843b02e4a55d854156bd53e46a0588e45 - Fix some regex issues with out-of-range characters and large char ranges. Previously, our regex code defined CHR_MAX as 0xfffffffe, which is a bad choice because it is outside the range of type "celt" (int32). Characters approaching that limit could lead to infinite loops in logic such as "for (c = a; c <= b; c++)" where c is of type celt but the range bounds are chr. Such loops will work safely only if CHR_MAX+1 is representable in celt, since c must advance to beyond b before the loop will exit. Fortunately, there seems no reason not to restrict CHR_MAX to 0x7ffffffe. It's highly unlikely that Unicode will ever assign codes that high, and none of our other backend encodings need characters beyond that either. In addition to modifying the macro, we have to explicitly enforce character range restrictions on the values of \u, \U, and \x escape sequences, else the limit is trivially bypassed. Also, the code for expanding case-independent character ranges in bracket expressions had a potential integer overflow in its calculation of the number of characters it could generate, which could lead to allocating too small a character vector and then overwriting memory. An attacker with the ability to supply arbitrary regex patterns could easily cause transient DOS via server crashes, and the possibility for privilege escalation has not been ruled out. Quite aside from the integer-overflow problem, the range expansion code was unnecessarily inefficient in that it always produced a result consisting of individual characters, abandoning the knowledge that we had a range to start with. If the input range is large, this requires excessive memory. Change it so that the original range is reported as-is, and then we add on any case-equivalent characters that are outside that range. With this approach, we can bound the number of individual characters allowed without sacrificing much. This patch allows at most 100000 individual characters, which I believe to be more than the number of case pairs existing in Unicode, so that the restriction will never be hit in practice. It's still possible for range() to take awhile given a large character code range, so also add statement-cancel detection to its loop. The downstream function dovec() also lacked cancel detection, and could take a long time given a large output from range(). Per fuzz testing by Greg Stark. Back-patch to all supported branches. Security: CVE-2016-0773 http://git.postgresql.org/pg/commitdiff/3bb3f42f3749d40b8d4de65871e8d828b18d4a45 - Last-minute updates for release notes. Security: CVE-2016-0773 http://git.postgresql.org/pg/commitdiff/02292845ac6d6ec09d79abf1dbb0538e14582743 - Add more chattiness in server shutdown. Early returns from the buildfarm show that there's a bit of a gap in the logging I added in 3971f64843b02e4a: the portion of CreateCheckPoint() after CheckPointGuts() can take a fair amount of time. Add a few more log messages in that section of code. This too shall be reverted later. http://git.postgresql.org/pg/commitdiff/7351e18286ec83461b386e23328d65fd4a538bba - Add still more chattiness in server shutdown. Further investigation says that there may be some slow operations after we've finished ShutdownXLOG(), so add some more log messages to try to isolate that. This is all temporary code too. http://git.postgresql.org/pg/commitdiff/41d505a7ffaf8c1678b931e15f74469c84fbb91e - Revert "Temporarily make pg_ctl and server shutdown a whole lot chattier." This reverts commit 3971f64843b02e4a55d854156bd53e46a0588e45 and a couple of followon debugging commits; I think we've learned what we can from them. http://git.postgresql.org/pg/commitdiff/c5e9b771275b93b09eec6b760677fe6c5e726ab2 - Avoid use of sscanf() to parse ispell dictionary files. It turns out that on FreeBSD-derived platforms (including OS X), the *scanf() family of functions is pretty much brain-dead about multibyte characters. In particular it will apply isspace() to individual bytes of input even when those bytes are part of a multibyte character, thus allowing false recognition of a field-terminating space. We appear to have little alternative other than instituting a coding rule that *scanf() is not to be used if the input string might contain multibyte characters. (There was some discussion of relying on "%ls", but that probably just moves the portability problem somewhere else, and besides it doesn't fully prevent BSD *scanf() from using isspace().) This patch is a down payment on that: it gets rid of use of sscanf() to parse ispell dictionary files, which are certainly at great risk of having a problem. The code is cleaner this way anyway, though a bit longer. In passing, improve a few comments. Report and patch by Artur Zakirov, reviewed and somewhat tweaked by me. Back-patch to all supported branches. http://git.postgresql.org/pg/commitdiff/51e78ab4ff3282963f5e8ba2633040829413aefa - Code review for isolationtester changes. Fix a few oversights in 38f8bdcac4982215beb9f65a19debecaf22fd470: don't leak memory in run_permutation(), remember when we've issued a cancel rather than issuing another one every 10ms, fix some typos in comments. http://git.postgresql.org/pg/commitdiff/d9dc2b4149c017c0a1d2045b858e8e0cc1a92464 - Make new deadlock isolation test more reproducible. The original formulation of 4c9864b9b4d87d02f07f40bb27976da737afdcab was extremely timing-sensitive, because it arranged for the deadlock detector to be running (and possibly unblocking the current query) at almost exactly the same time as isolationtester would be probing to see if the query is blocked. The committed expected-file assumed that the deadlock detection would finish first, but we see the opposite on both fast and slow buildfarm animals. Adjust the deadlock timeout settings to make it predictable that isolationtester *will* see the query as waiting before deadlock detection unblocks it. I used a 5s timeout for the same reasons mentioned in a7921f71a3c747141344d8604f6a6d7b4cddb2a9. http://git.postgresql.org/pg/commitdiff/b11d07b6a3fc64904731e3b9a467a2567bc7dcdb - Shift the responsibility for emitting "database system is shut down". Historically this message has been emitted at the end of ShutdownXLOG(). That's not an insane place for it in a standalone backend, but in the postmaster environment we've grown a fair amount of stuff that happens later, including archiver/walsender shutdown, stats collector shutdown, etc. Recent buildfarm experimentation showed that on slower machines there could be many seconds' delay between finishing ShutdownXLOG() and actual postmaster exit. That's fairly confusing, both for testing purposes and for DBAs. Hence, move the code that prints this message into UnlinkLockFiles(), so that it comes out just after we remove the postmaster's pidfile. That is a more appropriate definition of "is shut down" from the point of view of "pg_ctl stop", for example. In general, removing the pidfile should be the last externally-visible action of either a postmaster or a standalone backend; compare commit d73d14c271653dff10c349738df79ea03b85236c for instance. So this seems like a reasonably future-proof approach. http://git.postgresql.org/pg/commitdiff/d18643c4a6d5ac41b012abc5d11fb5a7ccddf6c5 - Fix typo in comment. http://git.postgresql.org/pg/commitdiff/2564be360a1d25a4c66e7cd34997ab027e0ec9a8 - Move pg_constraint.h function declarations to new file pg_constraint_fn.h. A pending patch requires exporting a function returning Bitmapset from catalog/pg_constraint.c. As things stand, that would mean including nodes/bitmapset.h in pg_constraint.h, which might be hazardous for the client-side includability of that header. It's not entirely clear whether any client-side code needs to include pg_constraint.h, but it seems prudent to assume that there is some such code somewhere. Therefore, split off the function definitions into a new file pg_constraint_fn.h, similarly to what we've done for some other catalog header files. http://git.postgresql.org/pg/commitdiff/72eee410d48dfb4e6f3a0b751c4b0057ca8adc81 - Remove GROUP BY columns that are functionally dependent on other columns. If a GROUP BY clause includes all columns of a non-deferred primary key, as well as other columns of the same relation, those other columns are redundant and can be dropped from the grouping; the pkey is enough to ensure that each row of the table corresponds to a separate group. Getting rid of the excess columns will reduce the cost of the sorting or hashing needed to implement GROUP BY, and can indeed remove the need for a sort step altogether. This seems worth testing for since many query authors are not aware of the GROUP-BY-primary-key exception to the rule about queries not being allowed to reference non-grouped-by columns in their targetlists or HAVING clauses. Thus, redundant GROUP BY items are not uncommon. Also, we can make the test pretty cheap in most queries where it won't help by not looking up a rel's primary key until we've found that at least two of its columns are in GROUP BY. David Rowley, reviewed by Julien Rouhaud http://git.postgresql.org/pg/commitdiff/d4c3a156cb46dcd1f9f97a8011bd94c544079bb5 - Refactor check_functional_grouping() to use get_primary_key_attnos(). If we ever get around to allowing functional dependency to be proven from other things besides simple primary keys, this code will need to be rethought, but that was true anyway. In the meantime, we might as well not have two very-similar routines for scanning pg_constraint. David Rowley, reviewed by Julien Rouhaud http://git.postgresql.org/pg/commitdiff/f144f73242acef574bc27a4c70e809a64806e4a4 - Further tweaking of deadlock isolation tests. The new deadlock-soft-2 test has a timing dependency too: it supposes that isolationtester will detect step s1b as waiting before the deadlock detector runs and grants it the lock. Adjust deadlock_timeout to ensure that that's true even in CLOBBER_CACHE_ALWAYS builds, where the wait detection query is quite slow. Per buildfarm member jaguarundi. http://git.postgresql.org/pg/commitdiff/caefc11ef6613683ddf8ded2081da3db238f463e - Re-pgindent isolationtester.c. Need to do some more hacking on this, and got annoyed that it's not indent clean. http://git.postgresql.org/pg/commitdiff/a361490806435fda6340fa13c0a881767c57c87a - Still further tweaking of deadlock isolation tests. It turns out that there is a second race condition in the new deadlock-hard test: once the deadlock detector fires, it's uncertain whether step s7a8 or step s8a1 will report first, because killing s8's transaction unblocks s7. So far, s7 has only been seen to report first in CLOBBER_CACHE_ALWAYS builds, but it's pretty reproducible there, and in theory it should sometimes occur in normal builds too. If s7 were a bit slower than usual, that could also break the test, since the existing expected-file assumes that we'll see s7a8 report the first time we check it after s8a1 completes. To fix, add a post-lock delay to s7a8. http://git.postgresql.org/pg/commitdiff/d03130d378b5fb071d231a7822784ad87268583a - isolationtester: don't repeat the is-it-waiting query when retrying a step. If we're retrying a step, then we already decided it was blocked on a lock, and there's no need to recheck that. The original coding of commit 38f8bdcac4982215beb9f65a19debecaf22fd470 resulted in a large number of is-it-waiting queries when dealing with multiple concurrently-blocked sessions, which is fairly pointless and also results in test failures in CLOBBER_CACHE_ALWAYS builds, where the is-it-waiting query is quite slow. This definition also permits appending pg_sleep() calls to steps where it's needed to control the order of finish of concurrent steps. Before, that did not work nicely because we'd decide that a step performing a sleep was not blocked and hang up waiting for it to finish, rather than noticing the completion of the concurrent step we're supposed to notice first. In passing, revise handling of removal of completed waiting steps to make it a bit less messy. http://git.postgresql.org/pg/commitdiff/9c9782f066e0ce5424b8706df2cce147cb78170f - Revert "isolationtester: don't repeat the is-it-waiting query when retrying a step." This mostly reverts commit 9c9782f066e0ce5424b8706df2cce147cb78170f. I left in the parts that rearranged removal of completed waiting steps; but the idea of not rechecking a step's blocked-ness isn't working. http://git.postgresql.org/pg/commitdiff/dca369320f6023b55feb49f281d394181fc57903 - Revert "Still further tweaking of deadlock isolation tests." This reverts commit d03130d378b5fb071d231a7822784ad87268583a. That was dependent on an isolationtester.c change that now proves to be broken; we will need to find another solution. http://git.postgresql.org/pg/commitdiff/3992188c2a8702bcb92140a840b5378b27468921 - Increase deadlock_timeout some more in the deadlock-hard isolation test. The previous value of 5s is inadequate for the buildfarm's CLOBBER_CACHE_ALWAYS animals: they take long enough to do the is-it-waiting queries that the timeout expires, allowing the database state to change, before isolationtester is done looking. Perhaps 10s will be enough. (If it isn't, I'm inclined to reduce the number of sessions involved.) http://git.postgresql.org/pg/commitdiff/e84e06d2b3fc48c514fd44f7ac390eb5f3e20d72 - Add missing "static" qualifier. Per buildfarm member pademelon. http://git.postgresql.org/pg/commitdiff/99a9d6d563f389ad8137984aac13c9c0bd37cb66 - Make GetLockStatusData's header comment resemble reality. The API spec for this function was changed completely (and for the better) by commit 3cba8999b343648c4c528432ab3d51400194e93b, but it didn't bother with anything as mundane as updating the comments. http://git.postgresql.org/pg/commitdiff/9b92e76f7b6dcdc2de6fae53a1c069297ba454fc Peter Eisentraut pushed: - Add support for systemd service notifications. Insert sd_notify() calls at server start and stop for integration with systemd. This allows the use of systemd service units of type "notify", which greatly simplifies the systemd configuration. Reviewed-by: Pavel Stěhule <pavel.steh...@gmail.com> http://git.postgresql.org/pg/commitdiff/7d17e683fcc28a1b371c7dd02935728cd2cbf9bf - doc: Fix stand-alone INSTALL file build. Commit 7d17e683fcc28a1b371c7dd02935728cd2cbf9bf introduced an external link. http://git.postgresql.org/pg/commitdiff/25e44518c16461d66fb6cec2063035d591db1def - Improve error message http://git.postgresql.org/pg/commitdiff/f8003e07f9715873796f39b1a36e07135f09d003 - Improve error reporting when location specified by postgres -D does not exist. Previously, the first error seen would be that postgresql.conf does not exist. But for the case where the whole directory does not exist, give an error message about that, together with a hint for how to create one. http://git.postgresql.org/pg/commitdiff/ac7238dc0faccb0ad077aa9922df6e75b0b1bda3 - Fix whitespace http://git.postgresql.org/pg/commitdiff/29b4b7bda64d751e1c66d8b7cab222b53781aafb Noah Misch pushed: - Comment on dead code in AtAbort_Portals() and AtSubAbort_Portals(). Reviewed by Tom Lane and Robert Haas. http://git.postgresql.org/pg/commitdiff/41baee7a9312eefb315b6b2973ac058c9efaa9cf - Force certain "pljava" custom GUCs to be PGC_SUSET. Future PL/Java versions will close CVE-2016-0766 by making these GUCs PGC_SUSET. This PostgreSQL change independently mitigates that PL/Java vulnerability, helping sites that update PostgreSQL more frequently than PL/Java. Back-patch to 9.1 (all supported versions). http://git.postgresql.org/pg/commitdiff/f4aa3a18a20d51575562520754aa376b3b08b2d0 - Accept pg_ctl timeout from the PGCTLTIMEOUT environment variable. Many automated test suites call pg_ctl. Buildfarm members axolotl, hornet, mandrill, shearwater, sungazer and tern have failed when server shutdown took longer than the pg_ctl default 60s timeout. This addition permits slow hosts to easily raise the timeout without us editing a --timeout argument into every test suite pg_ctl call. Back-patch to 9.1 (all supported versions) for the sake of automated testing. Reviewed by Tom Lane. http://git.postgresql.org/pg/commitdiff/2ffa86962077c588d8bdf6244e2ef960338d3883 - In pg_rewind test suite, triple promote timeout to 90s. Thirty seconds was not consistently enough for promotion to complete on buildfarm members sungazer and tern. Experiments suggest 43s would have been enough. Back-patch to 9.5, where pg_rewind was introduced. http://git.postgresql.org/pg/commitdiff/64d89a93c0a8b2ead0503684f54784bd071adad9 Andres Freund pushed: - Fix overeager pushdown of HAVING clauses when grouping sets are used. In 61444bfb we started to allow HAVING clauses to be fully pushed down into WHERE, even when grouping sets are in use. That turns out not to work correctly, because grouping sets can "produce" NULLs, meaning that filtering in WHERE and HAVING can have different results, even when no aggregates or volatile functions are involved. Instead only allow pushdown of empty grouping sets. It'd be nice to do better, but the exact mechanics of deciding which cases are safe are still being debated. It's important to give correct results till we find a good solution, and such a solution might not be appropriate for backpatching anyway. Bug: #13863 Reported-By: 'wrb' Diagnosed-By: Dean Rasheed Author: Andrew Gierth Reviewed-By: Dean Rasheed and Andres Freund Discussion: 20160113183558.12989.56...@wrigleys.postgresql.org Backpatch: 9.5, where grouping sets were introduced http://git.postgresql.org/pg/commitdiff/a6897efab92bc7e645b6c6d15274b8d61c53fe8f Joe Conway pushed: - Change delimiter used for display of NextXID NextXID has been rendered in the form of a pg_lsn even though it really is not. This can cause confusion, so change the format from %u/%u to %u:%u, per discussion on hackers. Complaint by me, patch by me and Bruce, reviewed by Michael Paquier and Alvaro. Applied to HEAD only. Author: Joe Conway, Bruce Momjian Reviewed-by: Michael Paquier, Alvaro Herrera Backpatch-through: master http://git.postgresql.org/pg/commitdiff/59a884e9854cb3cb7338394fb5f856209b040fb3 Bruce Momjian pushed: - pg_upgrade: Add C comment about NextXID delimiter. We don't test the catversion for the NextXID delimiter change, we just test the string contents; explain why. Reported-by: Michael Paquier http://git.postgresql.org/pg/commitdiff/13a6fa3634a70f58e043c78984cd2fb626abcc16 == Rejected Patches (for now) == No one was disappointed this week :-) == Pending Patches == Andreas 'ads' Scherbaum sent in two revisions of a patch to change the 32-bit counter in PL/pgsql's GET DIAGNOSTICS ... ROWCOUNT to 64-bit, allowing larger result sets. Michaël Paquier sent in a patch to fix psql's tab completion for ALTER FUNCTION. Alexander Korotkov sent in another revision of a patch to move PinBuffer and UnpinBuffer to atomics. Artur Zakirov sent in two more revisions of a patch to add fuzzy substring searching with the pg_trgm extension. Dmitry Ivanov sent in a patch to add phrase search to textsearch. David Steele sent in a patch to allow hiding messages below ERROR from the client. Fabien COELHO and Michaël Paquier traded patches to extend pgbench expressions with functions. Etsuro Fujita sent in a patch to fix a copy-pasto in the ExecForeignDelete documentation. David Steele sent in another revision of a patch to add a pgaudit extension. Fabien COELHO and Álvaro Herrera traded patches to extend pgbench stats, etc. Daniel Verité sent in another revision of a patch to create a crosstab view in psql. Iacob Catalin and Pavel Stěhule traded patches to add an ereport function to PL/PythonU. Teodor Sigaev sent in another revision of a patch to add tsvector editing functions. Corey Huinker sent in another revision of a patch to add generate_series(date, date[, integer]). Kyotaro HORIGUCHI and Fujii Masao traded patches to fix an incorrect formula for SysV IPC parameters. SAWADA Masahiko and Michaël Paquier traded patches to allow N > 1 synchronous standby servers. Amit Langote sent in two revisions of a patch to fix a typo in syncrep.c. Thomas Munro sent in another revision of a patch to add causal reads. Thomas Munro sent in another revision of a patch to detect SSI conflicts before reporting constraint violations. Konstantin Knizhnik sent in a patch to allow batch updating of indexes. Etsuro Fujita and Rushabh Lathia traded patches to speed up updating foreign tables through the PostgreSQL FDW. Michaël Paquier sent in four more revisions of a patch to fix hot standby checkpoints. SAWADA Masahiko sent in two more revisions of a patch to add a "frozen" bit to the visibility map. Heikki Linnakangas sent in a patch to fix the optimization to skip WAL-logging on table created in same xact. Haribabu Kommi sent in another revision of a patch to create a pg_hba_lookup function to get all matching pg_hba.conf entries. Kyotaro HORIGUCHI sent in a patch to help improve in-core regression tests. Michaël Paquier sent in two more revisions of a patch to help fix silent data loss on ext4 filesystems. Kyotaro HORIGUCHI sent in a patch to add IF (NOT) EXISTS support to tab completion in psql. Peter Geoghegan sent in another revision of a patch to fix an OpenSSL error queue bug. Vinayak Pokale sent in another revision of a patch to implement a vacuum progress checker. Filip Rembiałkowski sent in three revisions of a patch to make NOTIFY list de-duplication optional. Fabien COELHO sent in another revision of a patch to fix pgbench so it doesn't run much longer than the run length under certain pathological conditions. Robert Haas sent in a patch to push target-list evaluation down to the parallel worker whenever possible. Vitaly Burovoy sent in two revisions of a patch to make NOT NULL constraints follow SQL-2011. Peter Eisentraut sent in another revision of a patch to remove the WAL level "archive." Thomas Munro sent in another revision of a patch to add a new log line prefix for cluster name. Fujii Masao sent in another revision of a patch to check for a suitable index when refreshing a materialized view. Jim Nasby sent in a patch to convert pltcl from strings to objects. Jeff Janes sent in a patch to add s2k-count to pgcrypto. Jeff Janes sent in two revisions of a patch to fix a bug in StartupSUBTRANS. Pavel Stěhule and Jim Nasby traded patches to implement parse an ident to a text array. Konstantin Knizhnik sent in another revision of a patch to create an extensible transaction manager API. Stephen Frost sent in a patch to improve docs wrt catalog object ACLs. Magnus Hagander sent in a patch to update to the backup APIs to support non-exclusive backups. Vitaly Burovoy sent in another revision of a patch to add pg_size_bytes(). Aleksander Alekseev and Robert Haas traded patches to optimize dynahashes. Robbie Harwood sent in another revision of a patch to overhaul support for GSSAPI encryption. Artur Zakirov sent in another revision of a patch to add fuzzy substring searching to the pg_trgm extension. Fabien COELHO sent in four more revisions of a patch to extend pgbench with functions. Andreas 'ads' Scherbaum sent in another revision of a patch to allow PL/pgsql's GET DIAGNOSTICS to work with numbers of rows that overflow int32. Anastasia Lubennikova sent in another revision of a patch to implement covering + unique indexes. Magnus Hagander sent in a patch to make all the functions PL/pgsql exports are actually prefixed with plpgsql_. Andres Freund sent in a patch to make SetHintBit() a bit more aggressive, in order to fixes all the potential regressions created by another part of the patch which fixes the overaggressive flushing by the wal writer by only flushing every wal_writer_delay ms or wal_writer_flush_after bytes. Michaël Paquier sent in another revision of a patch to ensure that GinPageIs* actually return a boolean. Eugene Kazakov and Michaël Paquier traded patches to fix the TAP tests. Christian Ullrich sent in another revision of a patch to fix a crash with old Windows on a new CPU. Magnus Hagander sent in a patch to refactor receivelog.c to be less intertwined with itself. -- Sent via pgsql-announce mailing list (pgsql-announce@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-announce
