== PostgreSQL Weekly News - August 09 2015 == PostgreSQL 9.5 Alpha 2 Released. Test! http://www.postgresql.org/about/news/1604/
== PostgreSQL Product News == cstore_fdw 1.3, a columnar store extension for PostgreSQL, released. https://www.citusdata.com/blog/18-hadi/184-cstore-fdw-1-3-released pgbouncer 1.6, a light-weight connection pooler for PostgreSQL, released. http://pgbouncer.github.io/2015/08/pgbouncer-1-6/ pgCluu 2.4, a Perl program to audit PostgreSQL performance, released. http://pgcluu.darold.net/ PostgreSQL Replication, 2nd Edition, is out. https://www.packtpub.com/big-data-and-business-intelligence/postgresql-replication-second-edition 2UDA, a platform for data analytics, released. http://2ndquadrant.com/2uda == PostgreSQL Jobs for August == http://archives.postgresql.org/pgsql-jobs/2015-08/ == PostgreSQL Local == PostgresOpen 2015 will being held in Dallas, Texas September 16-18. http://2015.postgresopen.org/ PostgreSQL Session #7, will be held September 24th, 2015 in Paris, France, http://www.postgresql-sessions.org/7/about PGDay.IT 2015 will take place in Prato on October 23, 2015. http://pgday.it PostgreSQL Conference Europe 2015 will be held on October 27-30 in the Vienna Marriott Hotel, in Vienna, Austria. http://2015.pgconf.eu/ PGConf Silicon Valley 2015 is November 17-18 at the South San Francisco Convention Center. http://www.pgconfsv.com PGBR2015 (The Brazilian PostgreSQL Conference) will take place in Porto Alegre, Rio Grande do Sul, on November 18, 19 and 20. The CfP is open until August 31. http://pgbr.postgresql.org.br/2015/en/#call-for-papers == 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 == Andrew Dunstan pushed: - Allow TAP tests to run under Msys. The Msys DTK perl, which is required to run TAP tests under Msys as a native perl won't recognize the correct virtual paths, has its osname recorded in the Config module as 'msys' instead of 'MSWin32'. To avoid having to repeat the test a variable is created that is true iff the osname is either of these values, and is then used everywhere that matters. http://git.postgresql.org/pg/commitdiff/690ed2b76ab91eb79ea04ee2bfbdc8a2693f2a37 - Remove carriage returns from certain tap test output under Msys. These were causing spurious test failures. http://git.postgresql.org/pg/commitdiff/ff85fc8d0b3ae88221e20ee9b070c23248eb7921 - Allow pg_rewind tap tests to run with older File::Path versions. Older versions have rmtree but not remove_tree. The one-argument forms of these are equivalent, so replace remove_tree with rmtree. This allows the tests to be run on oldish Msys systems. http://git.postgresql.org/pg/commitdiff/7c29764a354a0e7deb3c28e1d5c38ff6662ee3f9 Tom Lane pushed: - Fix a number of places that produced XX000 errors in the regression tests. It's against project policy to use elog() for user-facing errors, or to omit an errcode() selection for errors that aren't supposed to be "can't happen" cases. Fix all the violations of this policy that result in ERRCODE_INTERNAL_ERROR log entries during the standard regression tests, as errors that can reliably be triggered from SQL surely should be considered user-facing. I also looked through all the files touched by this commit and fixed other nearby problems of the same ilk. I do not claim to have fixed all violations of the policy, just the ones in these files. In a few places I also changed existing ERRCODE choices that didn't seem particularly appropriate; mainly replacing ERRCODE_SYNTAX_ERROR by something more specific. Back-patch to 9.5, but no further; changing ERRCODE assignments in stable branches doesn't seem like a good idea. http://git.postgresql.org/pg/commitdiff/09cecdf285ea9f51aed669f9ea1ba840197d49d0 - contrib/isn now needs a .gitignore file. Oversight in commit cb3384a0cb4cf900622b77865f60e31259923079. Back-patch to 9.1, like that commit. http://git.postgresql.org/pg/commitdiff/fd7ed26c1a2353923be067dd84059f3ce3a5aff4 - Make modules/test_ddl_deparse/.gitignore match its siblings. Not sure why /tmp_check/ was omitted from this one, but even if it isn't really needed right now, it's inconsistent not to include it. http://git.postgresql.org/pg/commitdiff/e2b49db0f0c55196ae336e28bc142dddd38cad1e - Update 9.5 release notes through today. http://git.postgresql.org/pg/commitdiff/ecc2d16bc97d160d3b4beecfc46676bbaaf157a5 - Fix a PlaceHolderVar-related oversight in star-schema planning patch. In commit b514a7460d9127ddda6598307272c701cbb133b7, I changed the planner so that it would allow nestloop paths to remain partially parameterized, ie the inner relation might need parameters from both the current outer relation and some upper-level outer relation. That's fine so long as we're talking about distinct parameters; but the patch also allowed creation of nestloop paths for cases where the inner relation's parameter was a PlaceHolderVar whose eval_at set included the current outer relation and some upper-level one. That does *not* work. In principle we could allow such a PlaceHolderVar to be evaluated at the lower join node using values passed down from the upper relation along with values from the join's own outer relation. However, nodeNestloop.c only supports simple Vars not arbitrary expressions as nestloop parameters. createplan.c is also a few bricks shy of being able to handle such cases; it misplaces the PlaceHolderVar parameters in the plan tree, which is why the visible symptoms of this bug are "plan should not reference subplan's variable" and "failed to assign all NestLoopParams to plan nodes" planner errors. Adding the necessary complexity to make this work doesn't seem like it would be repaid in significantly better plans, because in cases where such a PHV exists, there is probably a corresponding join order constraint that would allow a good plan to be found without using the star-schema exception. Furthermore, adding complexity to nodeNestloop.c would create a run-time penalty even for plans where this whole consideration is irrelevant. So let's just reject such paths instead. Per fuzz testing by Andreas Seltenreich; the added regression test is based on his example query. Back-patch to 9.2, like the previous patch. http://git.postgresql.org/pg/commitdiff/85e5e222b1dd02f135a8c3bf387d0d6d88e669bd - Fix bogus "out of memory" reports in tuplestore.c. The tuplesort/tuplestore memory management logic assumed that the chunk allocation overhead for its memtuples array could not increase when increasing the array size. This is and always was true for tuplesort, but we (I, I think) blindly copied that logic into tuplestore.c without noticing that the assumption failed to hold for the much smaller array elements used by tuplestore. Given rather small work_mem, this could result in an improper complaint about "unexpected out-of-memory situation", as reported by Brent DeSpain in bug #13530. The easiest way to fix this is just to increase tuplestore's initial array size so that the assumption holds. Rather than relying on magic constants, though, let's export a #define from aset.c that represents the safe allocation threshold, and make tuplestore's calculation depend on that. Do the same in tuplesort.c to keep the logic looking parallel, even though tuplesort.c isn't actually at risk at present. This will keep us from breaking it if we ever muck with the allocation parameters in aset.c. Back-patch to all supported versions. The error message doesn't occur pre-9.3, not so much because the problem can't happen as because the pre-9.3 tuplestore code neglected to check for it. (The chance of trouble is a great deal larger as of 9.3, though, due to changes in the array-size-increasing strategy.) However, allowing LACKMEM() to become true unexpectedly could still result in less-than-desirable behavior, so let's patch it all the way back. http://git.postgresql.org/pg/commitdiff/8ea3e7a75c0d22c41c57f59c8b367059b97d0b66 - Fix pg_dump to dump shell types. Per discussion, it really ought to do this. The original choice to exclude shell types was probably made in the dark ages before we made it harder to accidentally create shell types; but that was in 7.3. Also, cause the standard regression tests to leave a shell type behind, for convenience in testing the case in pg_dump and pg_upgrade. Back-patch to all supported branches. http://git.postgresql.org/pg/commitdiff/3bdd7f90fc0a038ee8b5b3fd9f9507cf2f07a4b2 - Docs: add an explicit example about controlling overall greediness of REs. Per discussion of bug #13538. http://git.postgresql.org/pg/commitdiff/1b5d34ca6244a9296215325a9f82fb805e739f9e - Make real sure we don't reassociate joins into or out of SEMI/ANTI joins. Per the discussion in optimizer/README, it's unsafe to reassociate anything into or out of the RHS of a SEMI or ANTI join. An example from Piotr Stefaniak showed that join_is_legal() wasn't sufficiently enforcing this rule, so lock it down a little harder. I couldn't find a reasonably simple example of the optimizer trying to do this, so no new regression test. (Piotr's example involved the random search in GEQO accidentally trying an invalid case and triggering a sanity check way downstream in clause selectivity estimation, which did not seem like a sequence of events that would be useful to memorialize in a regression test as-is.) Back-patch to all active branches. http://git.postgresql.org/pg/commitdiff/6af9ee4c8c8f31cbf2e76166d1d9868876f60aea - Further fixes for degenerate outer join clauses. Further testing revealed that commit f69b4b9495269cc4 was still a few bricks shy of a load: minor tweaking of the previous test cases resulted in the same wrong-outer-join-order problem coming back. After study I concluded that my previous changes in make_outerjoininfo() were just accidentally masking the problem, and should be reverted in favor of forcing syntactic join order whenever an upper outer join's predicate doesn't mention a lower outer join's LHS. This still allows the chained-outer-joins style that is the normally optimizable case. I also tightened things up some more in join_is_legal(). It seems to me on review that what's really happening in the exception case where we ignore a mismatched special join is that we're allowing the proposed join to associate into the RHS of the outer join we're comparing it to. As such, we should *always* insist that the proposed join be a left join, which eliminates a bunch of rather dubious argumentation. The case where we weren't enforcing that was the one that was already known buggy anyway (it had a violatable Assert before the aforesaid commit) so it hardly deserves a lot of deference. Back-patch to all active branches, like the previous patch. The added regression test case failed in all branches back to 9.1, and I think it's only an unrelated change in costing calculations that kept 9.0 from choosing a broken plan. http://git.postgresql.org/pg/commitdiff/8703059c6b55c427100e00a09f66534b6ccbfaa1 - Fix eclass_useful_for_merging to give valid results for appendrel children. Formerly, this function would always return "true" for an appendrel child relation, because it would think that the appendrel parent was a potential join target for the child. In principle that should only lead to some inefficiency in planning, but fuzz testing by Andreas Seltenreich disclosed that it could lead to "could not find pathkey item to sort" planner errors in odd corner cases. Specifically, we would think that all columns of a child table's multicolumn index were interesting pathkeys, causing us to generate a MergeAppend path that sorts by all the columns. However, if any of those columns weren't actually used above the level of the appendrel, they would not get added to that rel's targetlist, which would result in being unable to resolve the MergeAppend's sort keys against its targetlist during createplan.c. Backpatch to 9.3. In older versions, columns of an appendrel get added to its targetlist even if they're not mentioned above the scan level, so that the failure doesn't occur. It might be worth back-patching this fix to older versions anyway, but I'll refrain for the moment. http://git.postgresql.org/pg/commitdiff/cde35cf4ae968d3366ea5358d2a754641e4c06c8 - Fix old oversight in join removal logic. Commit 9e7e29c75ad441450f9b8287bd51c13521641e3b introduced an Assert that join removal didn't reduce the eval_at set of any PlaceHolderVar to empty. At first glance it looks like join_is_removable ensures that's true --- but actually, the loop in join_is_removable skips PlaceHolderVars that are not referenced above the join due to be removed. So, if we don't want any empty eval_at sets, the right thing to do is to delete any now-unreferenced PlaceHolderVars from the data structure entirely. Per fuzz testing by Andreas Seltenreich. Back-patch to 9.3 where the aforesaid Assert was added. http://git.postgresql.org/pg/commitdiff/bab163e1218c0c36ccb0c0ef1b8f2d6feb2fc122 - Further adjustments to PlaceHolderVar removal. A new test case from Andreas Seltenreich showed that we were still a bit confused about removing PlaceHolderVars during join removal. Specifically, remove_rel_from_query would remove a PHV that was used only underneath the removable join, even if the place where it's used was the join partner relation and not the join clause being deleted. This would lead to a "too late to create a new PlaceHolderInfo" error later on. We can defend against that by checking ph_eval_at to see if the PHV could possibly be getting used at some partner rel. Also improve some nearby LATERAL-related logic. I decided that the check on ph_lateral needed to take precedence over the check on ph_needed, in case there's a lateral reference underneath the join being considered. (That may be impossible, but I'm not convinced of it, and it's easy enough to defend against the case.) Also, I realized that remove_rel_from_query's logic for updating LateralJoinInfos is dead code, because we don't build those at all until after join removal. Back-patch to 9.3. Previous versions didn't have the LATERAL issues, of course, and they also didn't attempt to remove PlaceHolderInfos during join removal. (I'm starting to wonder if changing that was really such a great idea.) http://git.postgresql.org/pg/commitdiff/89db83922a7f8ba223e233e262004b1745ece75d - Remove gram.y's precedence declaration for OVERLAPS. The allowed syntax for OVERLAPS, viz "row OVERLAPS row", is sufficiently constrained that we don't actually need a precedence declaration for OVERLAPS; indeed removing this declaration does not change the generated gram.c file at all. Let's remove it to avoid confusion about whether OVERLAPS has precedence or not. If we ever generalize what we allow for OVERLAPS, we might need to put back a precedence declaration for it, but we might want some other level than what it has today --- and leaving the declaration there would just risk confusion about whether that would be an incompatible change. Likewise, remove OVERLAPS from the documentation's precedence table. Per discussion with Noah Misch. Back-patch to 9.5 where we hacked up some nearby precedence decisions. http://git.postgresql.org/pg/commitdiff/1e3e1ae266502eb6a15a788f74d48b7c94196f56 Heikki Linnakangas pushed: - Clean up pg_rewind regression test script. Since commit 01f6bb4b2, TestLib.pm has exported path to tmp_check directory, so let's use that also for the pg_rewind test clusters etc. Also, in master, the $tempdir_short variable has not been used since commit 13d856e17, which moved the initdb-running code to TestLib.pm. Backpatch to 9.5. http://git.postgresql.org/pg/commitdiff/69b7a35c9ad8d8a467b5be5ab6ab2db7935e9b28 - Share transition state between different aggregates when possible. If there are two different aggregates in the query with same inputs, and the aggregates have the same initial condition and transition function, only calculate the state value once, and only call the final functions separately. For example, AVG(x) and SUM(x) aggregates have the same transition function, which accumulates the sum and number of input tuples. For a query like "SELECT AVG(x), SUM(x) FROM x", we can therefore accumulate the state function only once, which gives a nice speedup. David Rowley, reviewed and edited by me. http://git.postgresql.org/pg/commitdiff/804163bc25e979fcd91b02e58fa2d1c6b587cc65 - Fix pg_rewind when pg_xlog is a symlink. pg_xlog is often a symlink, typically to a different filesystem. Don't get confused and comlain about by that, and just always pretend that it's a normal directory, even if it's really a symlink. Also add a test case for this. Backpatch to 9.5. http://git.postgresql.org/pg/commitdiff/0e42397f42b370798461cbf3358185b520329f9f Fujii Masao pushed: - Make recovery rename tablespace_map to *.old if backup_label is not present. If tablespace_map file is present without backup_label file, there is no use of such file. There is no harm in retaining it, but it is better to get rid of the map file so that we don't have any redundant file in data directory and it will avoid any sort of confusion. It seems prudent though to just rename the file out of the way rather than delete it completely, also we ignore any error that occurs in rename operation as even if map file is present without backup_label file, it is harmless. Back-patch to 9.5 where tablespace_map file was introduced. Amit Kapila, reviewed by Robert Haas, Alvaro Herrera and me. http://git.postgresql.org/pg/commitdiff/dd85acf0c49ee6ea86b2ea0d4ff851b89c1f355a Joe Conway pushed: - Fix psql \d output of policies. psql neglected to wrap parenthesis around USING and WITH CHECK expressions -- fixed. Back-patched to 9.5 where RLS policies were introduced. http://git.postgresql.org/pg/commitdiff/c3cc844feb4a52fc57f53d129f33782d55f29340 Stephen Frost pushed: - RLS: Keep deny policy when only restrictive exist. Only remove the default deny policy when a permissive policy exists (either from the hook or defined by the user). If only restrictive policies exist then no rows will be visible, as restrictive policies shouldn't make rows visible. To address this requirement, a single "USING (true)" permissive policy can be created. Update the test_rls_hooks regression tests to create the necessary "USING (true)" permissive policy. Back-patch to 9.5 where RLS was added. Per discussion with Dean. http://git.postgresql.org/pg/commitdiff/dee0200f0276c0f9da930a2c926f90f5615f2d64 Robert Haas pushed: - Update comment to match behavior of latest code. Peter Geoghegan http://git.postgresql.org/pg/commitdiff/a6a235782083a98588e41a1298c8fcd89cfaa6b3 - Tab completion for CREATE SEQUENCE. Vik Fearing, reviewed by Brendan Jurd, Michael Paquier, and myself http://git.postgresql.org/pg/commitdiff/158e3bc8e2507244b0d1e87ee334f39b7400098a - Cap wal_buffers to avoid a server crash when it's set very large. It must be possible to multiply wal_buffers by XLOG_BLCKSZ without overflowing int, or calculations in StartupXLOG will go badly wrong and crash the server. Avoid that by imposing a maximum value on wal_buffers. This will be just under 2GB, assuming the usual value for XLOG_BLCKSZ. Josh Berkus, per an analysis by Andrew Gierth. http://git.postgresql.org/pg/commitdiff/369342cf70972a81e6be99b31593f31b73479d7f - Reduce ProcArrayLock contention by removing backends in batches. When a write transaction commits, it must clear its XID advertised via the ProcArray, which requires that we hold ProcArrayLock in exclusive mode in order to prevent concurrent processes running GetSnapshotData from seeing inconsistent results. When many processes try to commit at once, ProcArrayLock must change hands repeatedly, with each concurrent process trying to commit waking up to acquire the lock in turn. To make things more efficient, when more than one backend is trying to commit a write transaction at the same time, have just one of them acquire ProcArrayLock in exclusive mode and clear the XIDs of all processes in the group. Benchmarking reveals that this is much more efficient at very high client counts. Amit Kapila, heavily revised by me, with some review also from Pavan Deolasee. http://git.postgresql.org/pg/commitdiff/0e141c0fbb211bdd23783afa731e3eef95c9ad7a - Fix incorrect calculation in shm_mq_receive. If some, but not all, of the length word has already been read, and the next attempt to read sees exactly the number of bytes needed to complete the length word, or fewer, then we'll incorrectly read less than all of the available data. Antonin Houska http://git.postgresql.org/pg/commitdiff/df0a67f754c2c45c99237765f30856c5dd95949d - Fix attach-related race condition in shm_mq_send_bytes. Spotted by Antonin Houska. http://git.postgresql.org/pg/commitdiff/846f8c9483a8f31e45bf949db1721706a2765771 Andres Freund pushed: - Fix comment atomics.h. I appear to accidentally have switched the comments for pg_atomic_write_u32 and pg_atomic_read_u32 around. Also fix some minor typos I found while fixing. Noticed-By: Amit Kapila Backpatch: 9.5 http://git.postgresql.org/pg/commitdiff/073082bbb1adc4548132915874a001688514e64f - Fix debug message output when connecting to a logical slot. Previously the message erroneously printed the same LSN twice as the assignment to the start_lsn variable was before the message. Correct that. Reported-By: Marko Tiikkaja Author: Marko Tiikkaja Backpatch: 9.5, where logical decoding was introduced http://git.postgresql.org/pg/commitdiff/a855118be3f0682a2061448db5a87dec50717af4 - Rely on inline functions even if that causes warnings in older compilers. So far we have worked around the fact that some very old compilers do not support 'inline' functions by only using inline functions conditionally (or not at all). Since such compilers are very rare by now, we have decided to rely on inline functions from 9.6 onwards. To avoid breaking these old compilers inline is defined away when not supported. That'll cause "function x defined but not used" type of warnings, but since nobody develops on such compilers anymore that's ok. This change in policy will allow us to more easily employ inline functions. I chose to remove code previously conditional on PG_USE_INLINE as it seemed confusing to have code dependent on a define that's always defined. Blacklisting of compilers, like in c53f73879f, now has to be done differently. A platform template can define PG_FORCE_DISABLE_INLINE to force inline to be defined empty. Discussion: 20150701161447.gb30...@awork2.anarazel.de http://git.postgresql.org/pg/commitdiff/de6fd1c898f6eca82c2130a9dbb42d00da68d79e - Fix typo in commit de6fd1c. Per buildfarm members mandrill and hornet. http://git.postgresql.org/pg/commitdiff/18382ae7ede9a330d997ca4d53cb429ba2c4d5fd - Improve includes introduced in the replication origins patch. pg_resetxlog.h contained two superfluous includes, origin.h superfluously depended on logical.h, and pg_xlogdump's rmgrdesc.h only indirectly included origin.h. Backpatch: 9.5, where replication origins were introduced. http://git.postgresql.org/pg/commitdiff/3a145757a0cd19bfce770abeefa16af674e1bc09 - Address points made in post-commit review of replication origins. Amit reviewed the replication origins patch and made some good points. Address them. This fixes typos in error messages, docs and comments and adds a missing error check (although in a should-never-happen scenario). Discussion: caa4ek1jqubvewwkwumbpryfaje4190ug0y-oauhwq6td83v...@mail.gmail.com Backpatch: 9.5, where replication origins were introduced. http://git.postgresql.org/pg/commitdiff/18e8613564bf0a675d453eec1fceded7bce09988 - Don't include low level locking code from frontend code. Some frontend code like e.g. pg_xlogdump or pg_resetxlog, has to use backend headers. Unfortunately until now that code includes most of the locking code. It's generally not nice to expose such low level details, but de6fd1c898 made that a hard problem. We fall back to defining 'inline' away if the compiler doesn't support it - that can cause linker errors like on buildfarm animal pademelon if a inline function references backend only code. To fix that problem separate definitions from lock.h that are required from frontend code into lockdefs.h and use it in the relevant places. I've only removed the minimal amount of necessary definitions for now - it might turn out that we want more for other reasons. To avoid such details being exposed again put some checks against being included from frontend code into atomics.h, lock.h, lwlock.h and s_lock.h. It's otherwise fairly easy to indirectly include these headers. Discussion: 20150806070902.ge12...@awork2.anarazel.de http://git.postgresql.org/pg/commitdiff/4eda0a64705763854225a29703b606692af50e77 - Attempt to work around a 32bit xlc compiler bug from a different place. In de6fd1c8 I moved the the work around from 53f73879 into the aix template. The previous location was removed in the former commit, and I thought that it would be nice to emit a warning when running configure. That didn't turn out to work because at the point the template is included we don't know whether we're compiling a 32/64 bit binary and it's possible to install compilers for both on a 64 bit kernel/OS. So go back to a less ambitious approach and define PG_FORCE_DISABLE_INLINE in port/aix.h, without emitting a warning. We could try a more fancy approach, but it doesn't seem worth it. This requires moving the check for PG_FORCE_DISABLE_INLINE in c.h to after including the system headers included from therein which isn't perfect, as it seems slightly more robust to include all system headers in a similar environment. Oh well. Discussion: 20150807132000.gc13...@awork2.anarazel.de http://git.postgresql.org/pg/commitdiff/5a33650f24f9ad67a22c0f8a98c132c75034cfbf - Fix bug slowing down pgbench when -P is used. A removed check in ba3deeefb made all threads but the main one busy-loop when -P was used. All threads computed the time to the next time the progress report should be printed, but only the main thread did so and re-scheduled it only for the future. Reported-By: Jesper Pedersen Discussion: 55c4e190.3050...@redhat.com http://git.postgresql.org/pg/commitdiff/c2509944b1a090d64a4a18dcd524ff63ee0f0212 Noah Misch pushed: - Link $(WIN32RES) into single-file modules only when PGFILEDESC is set. Commit 0ffc201a51395ca71fe429ef86c872850a5850ee included this object unconditionally. Being unprepared for that, most external, single-file modules failed to build. This better aligns the GNU make build system with the heuristic in the MSVC build's Project::AddDirResourceFile(). In-tree, installed modules set PGFILEDESC, so they will see no change. Also, under PGXS, omit the nonfunctioning rule to build win32ver.rc. Back-patch to 9.5, where the aforementioned commit first appeared. http://git.postgresql.org/pg/commitdiff/c26170668c82eaaf28b6efbf76c5d1c206c27121 - Reconcile nodes/*funcs.c with recent work. A few of the discrepancies had semantic significance, but I did not track down the resulting user-visible bugs, if any. Back-patch to 9.5, where all but one discrepancy appeared. The _equalCreateEventTrigStmt() situation dates to 9.3 but does not affect semantics. catversion bump due to readfuncs.c field order changes. http://git.postgresql.org/pg/commitdiff/b8fe12a83622b350dc6849f8bb933bd8a86c1424 Bruce Momjian pushed: - docs: HTML-escape '>' in '=>' using HTML entities http://git.postgresql.org/pg/commitdiff/e641d7b22fae3086c1372fb0d117f629ec174a0b - 9.5 release notes: add non-LEAKPROOF view pushdown mention. Report by Dean Rasheed. Backpatch through 9.5 http://git.postgresql.org/pg/commitdiff/68b5163b45e3de569184a5f6d0956f7eccea76ad - 9.5 release notes: adjustments suggested by Andres Freund. Report by Andres Freund. Backpatch through 9.5 http://git.postgresql.org/pg/commitdiff/c4318c4065731c39eb7f9d14d245d46384880a9b - 9.5 release notes: mention change to CRC-32C. Report by Andres Freund. Backpatch through 9.5 http://git.postgresql.org/pg/commitdiff/c9351f03f380c505cc6d5f2daa3e2d007d9022c1 - 9.5 release notes: mention ON CONFLICT DO NOTHING for FDWs. Report by Peter Geoghegan. Backpatch through 9.5 http://git.postgresql.org/pg/commitdiff/58e09b902418d07545caec675d67265f1d510f4b - 9.5 release notes: updates from Andres Freund and Jeff Janes. Report by Andres Freund and Jeff Janes. Backpatch through 9.5 http://git.postgresql.org/pg/commitdiff/d6a8c943ab62317a5fca3b62224582d0d639df6b - 9.5 release notes: add increase buffer mapping partitions item. Report by Robert Haas, Andres Freund. Backpatch through 9.5 http://git.postgresql.org/pg/commitdiff/03249fe2c1b936af53c4dd78c29f4429fd63cdb1 - Document items that should appear in the major release notes http://git.postgresql.org/pg/commitdiff/88a30e8cc00d873627d8e3d58d2130879acf720f - docs: fix typo in rules.sgml. Report by Dean Rasheed. Patch by Dean Rasheed. Backpatch through 9.5 http://git.postgresql.org/pg/commitdiff/08c6178aa42063f4db771c3581a86049dc1c3da2 - docs: update major release notes item checklist http://git.postgresql.org/pg/commitdiff/d4aeb3dea217d1e6c004ea3112ad8845db2a5cda Kevin Grittner pushed: - Fix `make installcheck` for serializable transactions. Commit e5550d5fec66aa74caad1f79b79826ec64898688 added some new tests for ALTER TABLE which involved table scans. When default_transaction_isolation = 'serializable' these acquire relation-level SIReadLocks. The test results didn't cope with that. Add SIReadLock as the minimum lock level for purposes of these tests. This could also be fixed by excluding this type of lock from the my_locks view, but it would be a bug for SIReadLock to show up for a relation which was not otherwise locked, so do it this way to allow that sort of condition to cause a regression test failure. There is some question whether we could avoid taking SIReadLocks during these operations, but confirming the safety of that and figuring out how to avoid the locks is not trivial, and would be a separate patch. Backpatch to 9.4 where the new tests were added. http://git.postgresql.org/pg/commitdiff/253de7e1eb9abbcf57e6c229a8a38abd6455c7de Álvaro Herrera pushed: - Fix BRIN to use SnapshotAny during summarization. For correctness of summarization results, it is critical that the snapshot used during the summarization scan is able to see all tuples that are live to all transactions -- including tuples inserted or deleted by in-progress transactions. Otherwise, it would be possible for a transaction to insert a tuple, then idle for a long time while a concurrent transaction executes summarization of the range: this would result in the inserted value not being considered in the summary. Previously we were trying to use a MVCC snapshot in conjunction with adding a "placeholder" tuple in the index: the snapshot would see all committed tuples, and the placeholder tuple would catch insertions by any new inserters. The hole is that prior insertions by transactions that are still in progress by the time the MVCC snapshot was taken were ignored. Kevin Grittner reported this as a bogus error message during vacuum with default transaction isolation mode set to repeatable read (because the error report mentioned a function name not being invoked during), but the problem is larger than that. To fix, tweak IndexBuildHeapRangeScan to have a new mode that behaves the way we need using SnapshotAny visibility rules. This change simplifies the BRIN code a bit, mainly by removing large comments that were mistaken. Instead, rely on the SnapshotAny semantics to provide what it needs. (The business about a placeholder tuple needs to remain: that covers the case that a transaction inserts a a tuple in a page that summarization already scanned.) Discussion: https://www.postgresql.org/message-id/20150731175700.gx2...@postgresql.org In passing, remove a couple of unused declarations from brin.h and reword a comment to be proper English. This part submitted by Kevin Grittner. Backpatch to 9.5, where BRIN was introduced. http://git.postgresql.org/pg/commitdiff/2834855cb9fde734ce12f59694522c10bf0c0205 Tatsuo Ishii pushed: - Fix broken multibyte regression tests. commit 9043Fe390f4f0b4586cfe59cbd22314b9c3e2957 broke multibyte regression tests because the commit removes the warning message when temporary hash indexes is created, which has been added by commit 07af523870bcfe930134054febd3a6a114942e5b. Back patched to 9.5 stable tree. http://git.postgresql.org/pg/commitdiff/efc1610b64b04e7cf08cc1d6c608ede8b7d5ff07 Magnus Hagander pushed: - Fix typo in LDAP example. Reported by William Meitzen http://git.postgresql.org/pg/commitdiff/2a330d551ca9414a3ccd80420bb8b7071bdf8b00 == Rejected Patches (for now) == No one was disappointed this week :-) == Pending Patches == Michael Paquier sent in a patch to improve test coverage of extensions with pg_dump. Anastasia Lubennikova sent in two more revisions of a patch to add a microvacuum for GiST. Michael Paquier sent in a patch to fix an infelicity in the TAP tests for pg_rewind. Jeff Janes sent in a PoC patch to fix some bloating caused by a buggy interaction between GIN and the FSM. David Rowley sent in a patch to make cost_agg() with AGG_HASHED account for startup costs. Takashi Horikawa sent in a patch to allow a wal_buffer setting over 2GB. Michael Paquier sent in a patch to enforce the lock to AccessExclusiveLock should two locks of any subcommands differ. Kevin Grittner sent in a patch to removed some unused declarations in the BRIN code. Ildus Kurbangaliev, Robert Haas, and Amit Kapila traded patches to extend pg_stat_activity and show lwlocks. Amit Kapila sent in two more revisions of a patch to rename the mapfile if a backupfile is not present. David Rowley sent in a patch to allow doing a GROUP BY before a JOIN. Fabrízio de Royes Mello sent in three more revisions of a patch to reduce lock level for autovac reloptions in ALTER TABLE SET... Robert Haas sent in a patch to require that all workers have an entry in BackendList. Amit Langote sent in a patch to fix an issue where ON CONFLICT DO UPDATE using EXCLUDED.column wrongly gives an error about mismatched types. Stepan Rutz sent in a patch to add some hints as to which column names are causing an issue. Haribabu Kommi sent in a PoC patch to add a cache table. Andres Freund sent in four more revisions of a patch to ratchet up the compiler requirements for 9.6. Robert Abraham sent in a patch to enable creation of GIN indexes on very large tables by replacing repalloc with repalloc_huge in ginCombineData in src/backend/access/ginbulk.c. David Rowley sent in two more revisions of a patch to speed up timestamptz out. Robert Haas sent in a patch to bring comments on InitializeMaxBackends in line with the current reality. Álvaro Herrera sent in a patch to insure that BRIN pages get initialized. Michael Paquier sent in another revision of a patch to add facilities for new types of auth, as md5-hashed passwords may not be secure enough. Satoshi Nagayasu sent in a patch to add 9.5 support for pg_filedump. Heikki Linnakangas sent in a patch sort buffers in checkpoints. Satoshi Nagayasu sent in a patch to fix an Assert failure in pg_stat_statements when queryId is set by other module which is loaded prior to pg_stat_statements in the shared_preload_libraries parameter. Tom Lane sent in a patch to SS_finalize_plan processing to the end of planning, part of the path-ification of the upper planner. Alexander Korotkov sent in a WIP patch to rework the access method interface. Daniel Verite sent in a patch to add a \pivot command to psql. Andrew Dunstan and Michael Paquier traded patches to make TAP test deal better with working directories. -- Sent via pgsql-announce mailing list (pgsql-announce@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-announce
