== PostgreSQL Weekly News - September 11 2016 == - Mailing list pgsql-announce
| From | David Fetter |
|---|---|
| Subject | == PostgreSQL Weekly News - September 11 2016 == |
| Date | |
| Msg-id | 20160911220711.GA25430@fetter.org Whole thread Raw |
| List | pgsql-announce |
== PostgreSQL Weekly News - September 11 2016 == The Korean Users Group will hold its first PGDay event on October 15, 2016 in Seoul. http://pgday.postgresql.kr/ PGDay Austin 2016, will take place on November 12, 2016. Submission deadline is September 21, 2016 by midnight CST. Details and submission form at: https://www.postgresql.us/events/2016/austin PGDay.IT 2016 will take place in Prato on December the 13th 2016. http://pgday.it == PostgreSQL Product News == pgloader 3.3.1, a bulk loader for PostgreSQL, released. http://pgloader.io/ pgBadger v9.0, a PostgreSQL log analyzer and graph tool written in Perl, released. https://github.com/dalibo/pgbadger/releases/ PostGIS 2.3.0beta1, the industry standard geographic information system package for PostgreSQL, released. http://postgis.net/ PGroonga 1.1.1, a full text search platform for all languages, released. http://groonga.org/en/blog/2016/08/31/pgroonga-1.1.1.html == PostgreSQL Jobs for September == http://archives.postgresql.org/pgsql-jobs/2016-09/threads.php == PostgreSQL Local == PostgresOpen 2016 in will be held in Dallas, Texas September 13-16. https://2016.postgresopen.org/ PostgreSQL Session will be held on September 22th, 2016, in Lyon, France. http://blog.dalibo.com/2016/05/13/CFP-pgsession-lyon.html Postgres Vision 2016 will be held October 11-13, 2016, in San Francisco. http://postgresvision.com/ PostgreSQL Conference Europe will take place in Tallin, Estonia, on November 1-4, 2016. Early bird registration is open until September 14th, 2016. http://2016.pgconf.eu/registration/ PgConf Silicon Valley 2016 will be held on November 14-16, 2016. http://www.pgconfsv.com/ CHAR(16) will take place in New York, December 6, 2016. Call for papers is open until midnight (EDT) September 13, 2016. http://charconference.org/ == 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 david@fetter.org, German language to pwn@pgug.de, Italian language to pwn@itpug.org. == Applied Patches == Simon Riggs pushed: - Dirty replication slots when using sql interface. When pg_logical_slot_get_changes(...) sets confirmed_flush_lsn to the point at which replay stopped, it doesn't dirty the replication slot. So if the replay didn't cause restart_lsn or catalog_xmin to change as well, this change will not get written out to disk. Even on a clean shutdown. If Pg crashes or restarts, a subsequent pg_logical_slot_get_changes(...) call will see the same changes already replayed since it uses the slot's confirmed_flush_lsn as the start point for fetching changes. The caller can't specify a start LSN when using the SQL interface. Mark the slot as dirty after reading changes using the SQL interface so that users won't see repeated changes after a clean shutdown. Repeated changes still occur when using the walsender interface or after an unclean shutdown. Craig Ringer http://git.postgresql.org/pg/commitdiff/d851bef2d60ff9345249ff67c053e37fe4b364cc - Document LSN acronym in WAL Internals. We previously didn't mention what an LSN actually was. Simon Riggs and Michael Paquier http://git.postgresql.org/pg/commitdiff/ec03f4121cec6cf885bf40d9dfb53b8368251e99 - Add debug check function LWLockHeldByMeInMode(). Tests whether my process holds a lock in given mode. Add initial usage in MarkBufferDirty(). Thomas Munro http://git.postgresql.org/pg/commitdiff/016abf1fb8333de82a259af0cc7572a4b868023b - Fix VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL. lazy_truncate_heap() was waiting for VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL, but in microseconds not milliseconds as originally intended. Found by code inspection. Simon Riggs http://git.postgresql.org/pg/commitdiff/dcb12ce8d8691e0e526d3f38d14c4d7fc9c664f5 - Fix minor memory leak in Standby startup. StandbyRecoverPreparedTransactions() leaked the buffer used for two phase state file. This was leaked once at startup and at every shutdown checkpoint seen. Backpatch to 9.6 Stas Kelvich http://git.postgresql.org/pg/commitdiff/67c6bd1ca3ce75778138bf4713444a5a6b46032e - Correct TABLESAMPLE docs. Revert to original use of word “sample”, though with clarification, per Tom Lane. Discussion: 29052.1471015383@sss.pgh.pa.us http://git.postgresql.org/pg/commitdiff/f66472428a51fc484bc5ca81791924d06a6f096d - Fix corruption of 2PC recovery with subxacts. Reading 2PC state files during recovery was borked, causing corruptions during recovery. Effect limited to servers with 2PC, subtransactions and recovery/replication. Stas Kelvich, reviewed by Michael Paquier and Pavan Deolasee http://git.postgresql.org/pg/commitdiff/ec253de1fd2e6002122de80815ac5b963af8277c Tom Lane pushed: - Relax transactional restrictions on ALTER TYPE ... ADD VALUE. To prevent possibly breaking indexes on enum columns, we must keep uncommitted enum values from getting stored in tables, unless we can be sure that any such column is new in the current transaction. Formerly, we enforced this by disallowing ALTER TYPE ... ADD VALUE from being executed at all in a transaction block, unless the target enum type had been created in the current transaction. This patch removes that restriction, and instead insists that an uncommitted enum value can't be referenced unless it belongs to an enum type created in the same transaction as the value. Per discussion, this should be a bit less onerous. It does require each function that could possibly return a new enum value to SQL operations to check this restriction, but there aren't so many of those that this seems unmaintainable. Andrew Dunstan and Tom Lane Discussion: <4075.1459088427@sss.pgh.pa.us> http://git.postgresql.org/pg/commitdiff/15bc038f9bcd1a9af3f625caffafc7c20322202d - Make locale-dependent regex character classes work for large char codes. Previously, we failed to recognize Unicode characters above U+7FF as being members of locale-dependent character classes such as [[:alpha:]]. (Actually, the same problem occurs for large pg_wchar values in any multibyte encoding, but UTF8 is the only case people have actually complained about.) It's impractical to get Spencer's original code to handle character classes or ranges containing many thousands of characters, because it insists on considering each member character individually at regex compile time, whether or not the character will ever be of interest at run time. To fix, choose a cutoff point MAX_SIMPLE_CHR below which we process characters individually as before, and deal with entire ranges or classes as single entities above that. We can actually make things cheaper than before for chars below the cutoff, because the color map can now be a simple linear array for those chars, rather than the multilevel tree structure Spencer designed. It's more expensive than before for chars above the cutoff, because we must do a binary search in a list of high chars and char ranges used in the regex pattern, plus call iswalpha() and friends for each locale-dependent character class used in the pattern. However, multibyte encodings are normally designed to give smaller codes to popular characters, so that we can expect that the slow path will be taken relatively infrequently. In any case, the speed penalty appears minor except when we have to apply iswalpha() etc. to high character codes at runtime --- and the previous coding gave wrong answers for those cases, so whether it was faster is moot. Tom Lane, reviewed by Heikki Linnakangas Discussion: <15563.1471913698@sss.pgh.pa.us> http://git.postgresql.org/pg/commitdiff/c54159d44ceaba26ceda9fea1804f0de122a8f30 - Cosmetic code cleanup in commands/extension.c. Some of the comments added by the CREATE EXTENSION CASCADE patch were a bit sloppy, and I didn't care for redeclaring the same local variable inside a nested block either. No functional changes. http://git.postgresql.org/pg/commitdiff/25794e841e5b86a0f90fac7f7f851e5d950e51e2 - Repair whitespace in initdb message. What used to be four spaces somehow turned into a tab and a couple of spaces in commit a00c58314, no doubt from overhelpful emacs autoindent. Noted by Peter Eisentraut. http://git.postgresql.org/pg/commitdiff/a2ee579b6def8e0bde876c6c2fc9d4b8ec2b6b67 - Teach appendShellString() to not quote strings containing "-". Brain fade in commit a00c58314: I was thinking that a string starting with "-" could be taken as a switch depending on command line syntax. That's true, but having appendShellString() quote it will not help, so we may as well not do so. Per complaint from Peter Eisentraut. http://git.postgresql.org/pg/commitdiff/cdc70597c9ba62aad08a46e55c0c783bf4c21c9c - Guard against possible memory allocation botch in batchmemtuples(). Negative availMemLessRefund would be problematic. It's not entirely clear whether the case can be hit in the code as it stands, but this seems like good future-proofing in any case. While we're at it, insist that the value be not merely positive but not tiny, so as to avoid doing a lot of repalloc work for little gain. Peter Geoghegan Discussion: <CAM3SWZRVkuUB68DbAkgw=532gW0f+fofKueAMsY7hVYi68MuYQ@mail.gmail.com> http://git.postgresql.org/pg/commitdiff/f032722f86a709277d44a317a3bc8acd74861a72 - Doc: small improvements for documentation about VACUUM freezing. Mostly, explain how row xmin's used to be replaced by FrozenTransactionId and no longer are. Do a little copy-editing on the side. Per discussion with Egor Rogov. Back-patch to 9.4 where the behavioral change occurred. Discussion: <575D7955.6060209@postgrespro.ru> http://git.postgresql.org/pg/commitdiff/975768f8eae2581b89ceafe8b16a77ff375207fe - Add a HINT for client-vs-server COPY failure cases. Users often get confused between COPY and \copy and try to use client-side paths with COPY. The server then cannot find the file (if remote), or sees a permissions problem (if local), or some variant of that. Emit a hint about this in the most common cases. In future we might want to expand the set of errnos for which the hint gets printed, but be conservative for now. Craig Ringer, reviewed by Christoph Berg and Tom Lane Discussion: <CAMsr+YEqtD97qPEzQDqrCt5QiqPbWP_X4hmvy2pQzWC0GWiyPA@mail.gmail.com> http://git.postgresql.org/pg/commitdiff/4f405c8ef4704b7fa7fd8ac14a66c5f5d13722c4 - Doc: minor documentation improvements about extensions. Document the formerly-undocumented behavior that schema and comment control-file entries for an extension are honored only during initial installation, whereas other properties are also honored during updates. While at it, do some copy-editing on the recently-added docs for CREATE EXTENSION ... CASCADE, use links for some formerly vague cross references, and make a couple other minor improvements. Back-patch to 9.6 where CASCADE was added. The other parts of this could go further back, but they're probably not important enough to bother. http://git.postgresql.org/pg/commitdiff/bd180b607927c7757af17cd6fce0e545e5c48584 - Support renaming an existing value of an enum type. Not much to be said about this patch: it does what it says on the tin. In passing, rename AlterEnumStmt.skipIfExists to skipIfNewValExists to clarify what it actually does. In the discussion of this patch we considered supporting other similar options, such as IF EXISTS on the type as a whole or IF NOT EXISTS on the target name. This patch doesn't actually add any such feature, but it might happen later. Dagfinn Ilmari Mannsåker, reviewed by Emre Hasegeli Discussion: <CAO=2mx6uvgPaPDf-rHqG8=1MZnGyVDMQeh8zS4euRyyg4D35OQ@mail.gmail.com> http://git.postgresql.org/pg/commitdiff/0ab9c56d0fe3acc9d4717a9cbac6ef3369275b90 - Don't print database's tablespace in pg_dump -C --no-tablespaces output. If the database has a non-default tablespace, we emitted a TABLESPACE clause in the CREATE DATABASE command emitted by -C, even if --no-tablespaces was also specified. This seems wrong, and it's inconsistent with what pg_dumpall does, so change it. Per bug #14315 from Danylo Hlynskyi. Back-patch to 9.5. The bug is much older, but it'd be a more invasive change before 9.5 because dumpDatabase() hasn't got an easy way to get to the outputNoTablespaces flag. Doesn't seem worth the work given the lack of previous complaints. Report: <20160908081953.1402.75347@wrigleys.postgresql.org> http://git.postgresql.org/pg/commitdiff/e97e9c57bd22b2dfbfaf41f7d5c69789f7fad554 - Allow pg_dump to dump non-extension members of an extension-owned schema. Previously, if a schema was created by an extension, a normal pg_dump run (not --binary-upgrade) would summarily skip every object in that schema. In a case where an extension creates a schema and then users create other objects within that schema, this does the wrong thing: we want pg_dump to skip the schema but still create the non-extension-owned objects. There's no easy way to fix this pre-9.6, because in earlier versions the "dump" status for a schema is just a bool and there's no way to distinguish "dump me" from "dump my members". However, as of 9.6 we do have enough state to represent that, so this is a simple correction of the logic in selectDumpableNamespace. In passing, make some cosmetic fixes in nearby code. Martín Marqués, reviewed by Michael Paquier Discussion: <99581032-71de-6466-c325-069861f1947d@2ndquadrant.com> http://git.postgresql.org/pg/commitdiff/df5d9bb8d5074138e6fea63ac8acd9b95a0eb859 - Avoid reporting "cache lookup failed" for some user-reachable cases. We have a not-terribly-thoroughly-enforced-yet project policy that internal errors with SQLSTATE XX000 (ie, plain elog) should not be triggerable from SQL. record_in, domain_in, and PL validator functions all failed to meet this standard, because they threw plain elog("cache lookup failed for XXX") errors on bad OIDs, and those are all invokable from SQL. For record_in, the best fix is to upgrade typcache.c (lookup_type_cache) to throw a user-facing error for this case. That seems consistent because it was more than halfway there already, having user-facing errors for shell types and non-composite types. Having done that, tweak domain_in to rely on the typcache to throw an appropriate error. (This costs little because InitDomainConstraintRef would fetch the typcache entry anyway.) For the PL validator functions, we already have a single choke point at CheckFunctionValidatorAccess, so just fix its error to be user-facing. Dilip Kumar, reviewed by Haribabu Kommi Discussion: <87wpxfygg9.fsf@credativ.de> http://git.postgresql.org/pg/commitdiff/967a7b0fc9c8f4e07b697148238566203cb060de - In PageIndexTupleDelete, don't assume stored item lengths are MAXALIGNed. PageAddItem stores the item length as-is. It MAXALIGN's the amount of space actually allocated for each tuple, but not the stored length. PageRepairFragmentation, PageIndexMultiDelete, and PageIndexDeleteNoCompact are all on board with this and MAXALIGN item lengths after fetching them. But PageIndexTupleDelete expects the stored length to be a MAXALIGN multiple already. This accidentally works for existing index AMs because they all maxalign their tuple sizes internally; but we don't do that for heap tuples, and it shouldn't be a requirement for index tuples either. So, sync PageIndexTupleDelete with the rest of bufpage.c by having it maxalign the item size after fetching. Also add a check that pd_special is maxaligned, to ensure that the test "(offset + size) > phdr->pd_special" is still doing the right thing. (If offset and pd_special are aligned, it doesn't matter whether size is.) Again, this is in sync with the rest of the routines here, except for PageAddItem which doesn't test because it doesn't actually do anything for which pd_special alignment matters. This shouldn't have any immediate functional impact; it just adds the flexibility to use PageIndexTupleDelete on index tuples with non-aligned lengths. Discussion: <3814.1473366762@sss.pgh.pa.us> http://git.postgresql.org/pg/commitdiff/984d0a14e8d0141a68da5bd56ce6821042298904 - Invent PageIndexTupleOverwrite, and teach BRIN and GiST to use it. PageIndexTupleOverwrite performs approximately the same function as PageIndexTupleDelete (or PageIndexDeleteNoCompact) followed by PageAddItem targeting the same item pointer offset. But in the case where the new tuple is the same size as the old, it avoids shuffling other data around on the page, because the new tuple is placed where the old one was rather than being appended to the end of the page. This has been shown to provide a substantial speedup for some GiST use-cases. Also, this change allows some API simplifications: we can get rid of the rather klugy and error-prone PAI_ALLOW_FAR_OFFSET flag for PageAddItemExtended, since that was used only to cover a corner case for BRIN that's better expressed by using PageIndexTupleOverwrite. Note that this patch causes a rather subtle WAL incompatibility: the physical page content change represented by certain WAL records is now different than it was before, because while the tuples have the same itempointer line numbers, the tuples themselves are in different places. I have not bumped the WAL version number because I think it doesn't matter unless you are trying to do bitwise comparisons of original and replayed pages, and in any case we're early in a devel cycle and there will probably be more WAL changes before v10 gets out the door. There is probably room to make use of PageIndexTupleOverwrite in SP-GiST and GIN too, but that is left for a future patch. Andrey Borodin, reviewed by Anastasia Lubennikova, whacked around a bit by me Discussion: <CAJEAwVGQjGGOj6mMSgMwGvtFd5Kwe6VFAxY=uEPZWMDjzbn4VQ@mail.gmail.com> http://git.postgresql.org/pg/commitdiff/b1328d78f88cdf4f7504004159e530b776f0de16 - Convert PageAddItem into a macro to save a few cycles. Nowadays this is just a backwards-compatibility wrapper around PageAddItemExtended, so let's avoid the extra level of function call. In addition, because pretty much all callers are passing constants for the two bool arguments, compilers will be able to constant-fold the conversion to a flags bitmask. Discussion: <552.1473445163@sss.pgh.pa.us> http://git.postgresql.org/pg/commitdiff/1a4be103a523db8d47b464463ba175cc664442b2 - Rewrite PageIndexDeleteNoCompact into a form that only deletes 1 tuple. The full generality of deleting an arbitrary number of tuples is no longer needed, so let's save some code and cycles by replacing the original coding with an implementation based on PageIndexTupleDelete. We can always get back the old code from git if we need it again for new callers (though I don't care for its willingness to mess with line pointers it wasn't told to mess with). Discussion: <552.1473445163@sss.pgh.pa.us> http://git.postgresql.org/pg/commitdiff/24992c6db9fd40f342db1f22747ec9e56483796d - Fix miserable coding in pg_stat_get_activity(). Commit dd1a3bccc replaced a test on whether a subroutine returned a null pointer with a test on whether &pointer->backendStatus was null. This accidentally failed to fail, at least on common compilers, because backendStatus is the first field in the struct; but it was surely trouble waiting to happen. Commit f91feba87 then messed things up further, changing the logic to local_beentry = pgstat_fetch_stat_local_beentry(curr_backend); if (!local_beentry) continue; beentry = &local_beentry->backendStatus; if (!beentry) { where the second "if" is now dead code, so that the intended behavior of printing a row with "<backend information not available>" cannot occur. I suspect this is all moot because pgstat_fetch_stat_local_beentry will never actually return null in this function's usage, but it's still very poor coding. Repair back to 9.4 where the original problem was introduced. http://git.postgresql.org/pg/commitdiff/ddc889317912fd8b654439701195a43cecfd4e79 - Improve unreachability recognition in elog() macro. Some experimentation with an older version of gcc showed that it is able to determine whether "if (elevel_ >= ERROR)" is compile-time constant if elevel_ is declared "const", but otherwise not so much. We had accounted for that in ereport() but were too miserly with braces to make it so in elog(). I don't know how many currently-interesting compilers have the same quirk, but in case it will save some code space, let's make sure that elog() is on the same footing as ereport() for this purpose. Back-patch to 9.3 where we introduced pg_unreachable() calls into elog/ereport. http://git.postgresql.org/pg/commitdiff/f2717c79eeecaf5997016d52fd81881301dcfc5e - Fix and simplify MSVC build's handling of xml/xslt/uuid dependencies. Solution.pm mistakenly believed that the xml option requires the xslt option, when actually the dependency is the other way around; and it believed that libxml requires libiconv, which is not necessarily so, so we shouldn't enforce it here. Fix the option cross-checking logic. Also, since AddProject already takes care of adding libxml and libxslt include and library dependencies to every project, there's no need for the custom code that did that in mkvcbuild. While at it, let's handle the similar dependencies for uuid in a similar fashion. Given the lack of field complaints about these overly strict build dependency requirements, there seems no need for a back-patch. Michael Paquier Discussion: <CAB7nPqR0+gpu3mRQvFjf-V-bMxmiSJ6NpTg9_WzVDL+a31cV2g@mail.gmail.com> http://git.postgresql.org/pg/commitdiff/28e5e5648cc3666537c393b2636c4aa34fdb22c1 - Allow CREATE EXTENSION to follow extension update paths. Previously, to update an extension you had to produce both a version-update script and a new base installation script. It's become more and more obvious that that's tedious, duplicative, and error-prone. This patch attempts to improve matters by allowing the new base installation script to be omitted. CREATE EXTENSION will install a requested version if it can find a base script and a chain of update scripts that will get there. As in the existing update logic, shorter chains are preferred if there's more than one possibility, with an arbitrary tie-break rule for chains of equal length. Also adjust the pg_available_extension_versions view to show such versions as installable. While at it, refactor the code so that CASCADE processing works for extensions requested during ApplyExtensionUpdates(). Without this, addition of a new requirement in an updated extension would require creating a new base script, even if there was no other reason to do that. (It would be easy at this point to add a CASCADE option to ALTER EXTENSION UPDATE, to allow the same thing to happen during a manually-commanded version update, but I have not done that here.) Tom Lane, reviewed by Andres Freund Discussion: <20160905005919.jz2m2yh3und2dsuy@alap3.anarazel.de> http://git.postgresql.org/pg/commitdiff/40b449ae84dcf71177d7749a7b0c582b64dc15f0 Bruce Momjian pushed: - C comment: align dashes in GroupState node header. Author: Jim Nasby http://git.postgresql.org/pg/commitdiff/f80049f76a32858601510eaaef19ab8160e4c9b3 - C comment: fix file name mention on line 1. Author: Amit Langote http://git.postgresql.org/pg/commitdiff/67e1e2aaff109c507da013c66009f048dda96f3e - 9.6 release notes: correct summary item about freeze Previously it less precisely talked about autovacuum. Backpatch-through: 9.6 http://git.postgresql.org/pg/commitdiff/c9cf432ef32a9d29323b9b079178c1a6be126ff8 Álvaro Herrera pushed: - Have "make coverage" recurse into contrib as well http://git.postgresql.org/pg/commitdiff/2093f6630500c9d5e122748ac7d3719855d71174 - Fix two src/test/modules Makefiles. commit_ts and test_pg_dump were declaring targets before including the PGXS stanza, which meant that the "all" target customarily defined as the first (and therefore default target) was not the default anymore. Fix that by moving those target definitions to after PGXS. commit_ts was initially good, but I broke it in commit 9def031bd2; test_pg_dump was born broken, probably copying from commit_ts' mistake. In passing, fix a comment mistake in test_pg_dump/Makefile. Backpatch to 9.6. Noted by Tom Lane. http://git.postgresql.org/pg/commitdiff/19acee8c5adb68b96222e41c084efbc9b31d397a - Fix locking a tuple updated by an aborted (sub)transaction. When heap_lock_tuple decides to follow the update chain, it tried to also lock any version of the tuple that was created by an update that was subsequently rolled back. This is pointless, since for all intents and purposes that tuple exists no more; and moreover it causes misbehavior, as reported independently by Marko Tiikkaja and Marti Raudsepp: some SELECT FOR UPDATE/SHARE queries may fail to return the tuples, and assertion-enabled builds crash. Fix by having heap_lock_updated_tuple test the xmin and return success immediately if the tuple was created by an aborted transaction. The condition where tuples become invisible occurs when an updated tuple chain is followed by heap_lock_updated_tuple, which reports the problem as HeapTupleSelfUpdated to its caller heap_lock_tuple, which in turn propagates that code outwards possibly leading the calling code (ExecLockRows) to believe that the tuple exists no longer. Backpatch to 9.3. Only on 9.5 and newer this leads to a visible failure, because of commit 27846f02c176; before that, heap_lock_tuple skips the whole dance when the tuple is already locked by the same transaction, because of the ancient HeapTupleSatisfiesUpdate behavior. Still, the buggy condition may also exist in more convoluted scenarios involving concurrent transactions, so it seems safer to fix the bug in the old branches too. Discussion: https://www.postgresql.org/message-id/CABRT9RC81YUf1=jsmWopcKJEro=VoeG2ou6sPwyOUTx_qteRsg@mail.gmail.com https://www.postgresql.org/message-id/48d3eade-98d3-8b9a-477e-1a8dc32a724d@joh.to http://git.postgresql.org/pg/commitdiff/5c609a742f294907512b946dbaf1feaa3b71ddc7 Peter Eisentraut pushed: - Add location field to DefElem. Add a location field to the DefElem struct, used to parse many utility commands. Update various error messages to supply error position information. To propogate the error position information in a more systematic way, create a ParseState in standard_ProcessUtility() and pass that to interested functions implementing the utility commands. This seems better than passing the query string and then reassembling a parse state ad hoc, which violates the encapsulation of the ParseState type. Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> http://git.postgresql.org/pg/commitdiff/49eb0fd0972d14014dd3533b1f1bf8c94c899883 - Make better use of existing enums in plpgsql plpgsql.h defines a number of enums, but most of the code passes them around as ints. Update structs and function prototypes to take enum types instead. This clarifies the struct definitions in plpgsql.h in particular. Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com> http://git.postgresql.org/pg/commitdiff/e0013deb5983303d945aacd56909ac4ce227fde1 Noah Misch pushed: - MSVC: Place gendef.pl temporary file in the target directory. Until now, it used the current working directory. This makes it safe for simultaneous invocations of gendef.pl, with different target directories, to run from a single current working directory, such as $(top_srcdir). The MSVC build system will soon rely on this. Christian Ullrich, reviewed by Michael Paquier. http://git.postgresql.org/pg/commitdiff/976a9bbd0251ea112898f85314646801e7e6207d - MSVC: Pass any user-set MSBFLAGS to MSBuild and VCBUILD. This is particularly useful to pass /m, to perform a parallel build. Christian Ullrich, reviewed by Michael Paquier. http://git.postgresql.org/pg/commitdiff/d299eb41dfc7b73dec80f22554b952f01c9d54a4 Andres Freund pushed: - Fix mdtruncate() to close fd.c handle of deleted segments. mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting it. That lead to a fd.c handle to a truncated file being kept open until backend exit. The issue appears to have been introduced way back in 1a5c450f3024ac5, before that the handle was closed inside FileUnlink(). The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE for temporary tables, truncate files in place (i.e. TRUNCATE itself is not affected), and the relation has to be bigger than 1GB. The consequences of a leaked fd.c handle aren't severe either. Discussion: <20160908220748.oqh37ukwqqncbl3n@alap3.anarazel.de> Backpatch: all supported releases http://git.postgresql.org/pg/commitdiff/769fd9d8e06bf862334a0e04134a3d2c665e5e5b - Improve scalability of md.c for large relations. So far md.c used a linked list of segments. That proved to be a problem when processing large relations, because every smgr.c/md.c level access to a page incurred walking through a linked list of all preceding segments. Thus making accessing pages O(#segments). Replace the linked list of segments hanging off SMgrRelationData with an array of opened segments. That allows O(1) access to individual segments, if they've previously been opened. Discussion: <20140331101001.GE13135@alap3.anarazel.de> Reviewed-By: Peter Geoghegan, Tom Lane (in an older version) http://git.postgresql.org/pg/commitdiff/45e191e3aa62d47a8bc1a33f784286b2051f45cb - Faster PageIsVerified() for the all zeroes case. That's primarily useful for testing very large relations, using sparse files. Discussion: <20140331101001.GE13135@alap3.anarazel.de> Reviewed-By: Peter Geoghegan http://git.postgresql.org/pg/commitdiff/417fefaf089fc0b73607cbbe8bcd0bc9e89d08ef Heikki Linnakangas pushed: - Implement binary heap replace-top operation in a smarter way. In external sort's merge phase, we maintain a binary heap holding the next tuple from each input tape. On each step, the topmost tuple is returned, and replaced with the next tuple from the same tape. We were doing the replacement by deleting the top node in one operation, and inserting the next tuple after that. However, you can do a "replace-top" operation more efficiently, in one "sift-up". A deletion will always walk the heap from top to bottom, but in a replacement, we can stop as soon as we find the right place for the new tuple. This is particularly helpful, if the tapes are not in completely random order, so that the next tuple from a tape is likely to land near the top of the heap. Peter Geoghegan, reviewed by Claudio Freire, with some editing by me. Discussion: <CAM3SWZRhBhiknTF_=NjDSnNZ11hx=U_SEYwbc5vd=x7M4mMiCw@mail.gmail.com> http://git.postgresql.org/pg/commitdiff/24598337c8d214ba8dcf354130b72c49636bba69 == Pending Patches == Michaël Paquier and Christian Ullrich traded patches to enable parallel builds with MSVC. Haribabu Kommi sent in another revision of a patch to add a pg_hba_file_settings system view. Craig Ringer sent in a patch to send catalog_xmin in hot standby feedback protocol, make walsender respect catalog_xmin in hot standby feedback messages, allow GetOldestXmin(...) to optionally disregard the catalog_xmin, and send catalog_xmin separately in hot_standby_feedback messages. Heikki Linnakangas sent in a patch to fix compilation with OpenSSL 1.1 and silence deprecation warnings with OpenSSL 1.1. Abhijit Menon-Sen sent in another revision of a patch to convert recovery.conf settings to GUCs. KaiGai Kohei sent in another revision of a patch to implement PassDownLimitBound for ForeignScan/CustomScan. Michaël Paquier sent in another revision of a patch to speed up 2PC transactions. Mithun Cy sent in another revision of a patch to cache hash index meta pages. Craig Ringer and Vladimir Gordiychuk traded patches to respect client-initiated CopyDone in walsender and allow streaming to be interrupted during ReorderBufferCommit. Claudio Freire, Masahiko Sawada, and Simon Riggs traded patches to enable using over 1GB of work_mem in VACUUM. Tom Lane sent in two revisions of a patch to let CREATE EXTENSION follow update chains. Simon Riggs sent in another revision of a patch to add a "patient" mode to LOCK TABLE. Daniel Vérité sent in another revision of a patch to add batch/pipelining support for libpq. Michaël Paquier and Christian Ullrich traded patches to do some cleanups in pgwin32_putenv, fix the load race in pgwin32_putenv() (and open the unload race), and pin any DLL as soon as seen when looking for _putenv on Windows. Vinayak Pokale sent in a patch to add pg_fdw_xact_resolver(). Gerdan Rezende dos Santos sent in another revision of a patch to add an option to pg_dumpall to exclude tables from the dump. Kyotaro HORIGUCHI sent in a patch to fix an illegal SJIS mapping. Etsuro Fujita sent in another revision of a patch to push more UPDATEs and DELETEs to the PostgreSQL FDW. Ashutosh Bapat and Amit Langote traded patches to add declarative table partitioning. Kyotaro HORIGUCHI sent in another revision of a patch to add IF NOT EXISTS support to psql's tab completion. David Steele sent in two more revisions of a patch to exclude additional directories in pg_basebackup. Pavan Deolasee sent in a patch to override compile time log levels of specific messages/modules. Heikki Linnakangas sent in four revisions of a patch to remove tuplesort merge pre-reading. Fabien COELHO sent in another revision of a patch to pgbench to permit storing select results into variables. Peter Geoghegan sent in another revision of a patch to add amcheck, a B-Tree integrity checking tool. Jim Nasby sent in another revision of a patch to fix a mistaken comment in nodeCtescan.c. Vik Fearing sent in two more revisions of a patch to add long options for pg_ctl waiting. Kyotaro HORIGUCHI sent in a PoC patch to use a radix tree to encoding characters of Shift JIS. Michaël Paquier sent in another revision of a patch to forbid the use of LF and CR characters in database and role names. Ildar Musin sent in another revision of a patch to enable index-only scans for some expressions. Amit Kapila sent in another revision of a patch to enable WAL logging for hash indexes. Michaël Paquier sent in three revisions of a patch to remove a useless dependency assumption libxml2 -> libxslt in MSVC scripts. Kuntal Ghosh sent in two more revisions of a patch to add a WAL consistency check facility. Masahiko Sawada sent in a patch to make lazy_scan_heap output how many all_frozen pages are skipped and add cheat_vacuum_table_size. Rahila Syed sent in another revision of a patch to get psql to error out when someone tries to set autocommit at the wrong spot. Ashutosh Bapat sent in another revision of a patch to enable pushing aggregates to a foreign server. Masahiko Sawada sent in a patch to add a --disable-page-skipping option to the vacuumdb command. Peter Eisentraut sent in another revision of a patch to add overflow checks to the money type input function. Victor Wagner sent in another revision of a patch to implement failover on libpq connect level. Stephen Frost sent in another revision of a patch to add support for restrictive RLS policies. Petr Jelinek sent in another revision of a patch to implement logical replication. Adam Brightwell sent in a patch to fix a mismatch between RLS and COPY. Andrew Borodin and Mikhail Bakhterev traded patches to improve the GiST penalty functions. Peter Eisentraut sent in another revision of a patch to add CREATE SEQUENCE AS <data type> clause. Ashutosh Bapat sent in a patch to support partition-wise joins for partitioned tables. Etsuro Fujita sent in another revision of a patch to push down more full joins in postgres_fdw. Pavel Stehule sent in two more revisions of a patch to add xmltable(). Kevin Grittner sent in another revision of a patch to add trigger transition tables. Thomas Munro sent in another revision of a patch to use kqeue when available. Dmitry Dolgov sent in a patch to add generic type subscription. Heikki Linnakangas sent in a patch to allow temp file access tracing. Vitaly Burovoy sent in another revision of a patch to add tab completion for CREATE DATABASE ... TEMPLATE ... to psql. Amit Kapila sent in a patch to add some simple tests for pg_stat_statements. Mattia sent in a patch to allow to_date() and to_timestamp() to accept localized month names. Corey Huinker sent in another revision of a patch to let file_fdw access COPY FROM PROGRAM. Peter Eisentraut sent in another revision of a patch to add a pg_sequences view. Peter Geoghegan sent in another revision of a patch to add parallel tuplesort for parallel B-tree index creation.
pgsql-announce by date: