== PostgreSQL Weekly News - February 05 2017 == The first pgDay Israel 2017 will take place on March 2, 2017. Registration is open. http://pgday.org.il/
Postgres Vision will take place in Boston, June 26 - 28, 2017. the CfP is open until February 24, 2017 at CFP AT PostgresVision DOT com. http://postgresvision.com/ == PostgreSQL Product News == Ora2Pg 18.0, a tool for migrating Oracle databases to PostgreSQL, released. http://ora2pg.darold.net/ psqlODBC 09.06.0100 released. https://odbc.postgresql.org/docs/release.html PostGIS 2.2.5 and 2.3.2, the industry standard geographic information system package for PostgreSQL, released. http://postgis.net/2017/01/30/postgis-2.2.5/ http://postgis.net/2017/01/31/postgis-2.3.2/ == PostgreSQL Jobs for February == http://archives.postgresql.org/pgsql-jobs/2017-02/ == PostgreSQL Local == PGConf India 2017 will be on March 2-3, 2017 in Bengaluru, Karnataka. http://pgconf.in/ PostgreSQL@SCaLE will take place on March 2-3, 2017, at Pasadena Convention Center, as part of SCaLE 15X. http://www.socallinuxexpo.org/scale/15x/ PgConf.Russia 2017 will take place on 15-17 March 2017 in Moscow. https://pgconf.ru/en PGDay Asia 2017 will be held March 17-18 in Singapore. http://tinyurl.com/pgDay-Asia-2017-Cfp Nordic PGDay 2017 will be held in Stockholm, Sweden, at the Sheraton Hotel, on March 21, 2017. https://2017.nordicpgday.org/ pgDay Paris 2017 will be held in Paris, France on March 23, 2017. http://2017.pgday.paris/ PGConf US 2017 CfP will be on March 28-31 in Jersey City, New Jersey. http://www.pgconf.us/2017/ PGCon 2017 will take place in Ottawa on 23-26 May. http://www.pgcon.org/2017/papers.php == 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. == Applied Patches == Stephen Frost pushed: - Handle ALTER EXTENSION ADD/DROP with pg_init_privs. In commit 6c268df, pg_init_privs was added to track the initial privileges of catalog objects and extensions. Unfortunately, that commit didn't include understanding of ALTER EXTENSION ADD/DROP, which allows the objects associated with an extension to be changed after the initial CREATE EXTENSION script has been run. The result of this meant that ACLs for objects added through ALTER EXTENSION ADD were not recorded into pg_init_privs and we would end up including those ACLs in pg_dump when we shouldn't have. This commit corrects that by making sure to have pg_init_privs updated when ALTER EXTENSION ADD/DROP is run, recording the permissions as they are at ALTER EXTENSION ADD time, and removing any if/when ALTER EXTENSION DROP is called. This issue was pointed out by Moshe Jacobson as commentary on bug #14456 (which was actually a bug about versions prior to 9.6 not handling custom ACLs on extensions correctly, an issue now addressed with pg_init_privs in 9.6). Back-patch to 9.6 where pg_init_privs was introduced. http://git.postgresql.org/pg/commitdiff/e54f75722c720b596ec5e72154cc899da199de5b - test_pg_dump TAP test whitespace cleanup. The formatting of the perl hashes used in the TAP tests for test_pg_dump was rather horribly inconsistent and made it more difficult than it really should have been to add new tests or adjust what tests are for what runs, etc. Reformat to clean that all up. Whitespace-only changes. http://git.postgresql.org/pg/commitdiff/fb94ca77f1400e236b00d432dccfbe4f1124971c - test_pg_dump: perltidy cleanup. As pointed out by Alvaro, we actually use perltidy on the perl scripts in the source tree, so go back to the results of a perltidy run for the test_pg_dump TAP script. To make it look slightly less tragic, I changed most of the independent arguments into long-form single arguments (eg: -f file.sql changed to be --file=file.sql) to avoid having them confusingly split across lines due to perltidy. Back-patch to 9.6, as the last patch was. http://git.postgresql.org/pg/commitdiff/58da8334308c26107ebb7ee06c99589e14bd882b - perltidy pg_dump TAP tests. The pg_dump TAP tests have gotten pretty far from what perltidy thinks they should be, so fix that, and in passing use long-form argument names with arguments passed via "=" in a similar vein to 58da833. No functional changes here, just whitespace and changing runs from "-f" to "--file=", and similar. http://git.postgresql.org/pg/commitdiff/6af8b89adba16f97bee0d3b01256861e10d0e4f1 - pg_dump: Fix handling of ALTER DEFAULT PRIVILEGES. In commit 23f34fa, we changed how ACLs were handled to use the new pg_init_privs catalog and to dump out the ACL commands as REVOKE+GRANT combinations instead of trying to REVOKE all rights always and then GRANT back just the ones which were in place. Unfortunately, the DEFAULT PRIVILEGES system didn't quite get the correct treatment with this change and ended up (incorrectly) only including positive GRANTs instead of both the REVOKEs and GRANTs necessary to preserve the correct privileges. There are only a couple cases where such REVOKEs are possible because, generally speaking, there's few rights which exist on objects by default to be revoked. Examples of REVOKEs which weren't being correctly preserved are when privileges are REVOKE'd from the creator/owner, like so: ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE SELECT ON TABLES FROM myrole; or when other default privileges are being revoked, such as EXECUTE rights granted to public for functions: ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC; Fix this by correctly working out what the correct REVOKE statements are (if any) and dump them out, just as we do for everything else. Noticed while developing additional regression tests for pg_dump, which will be landing shortly. Back-patch to 9.6 where the bug was introduced. http://git.postgresql.org/pg/commitdiff/e2090d9d20d8091c9478a674d9c22fc8006909ce Heikki Linnakangas pushed: - Remove leftover reference to "indirect blocks" in comment. Peter Geoghegan http://git.postgresql.org/pg/commitdiff/dbeca61c3535af2613000c4492848ca6da8a902f - Small fixes to the Perl scripts to create unicode conversion tables. Add missing semicolons in UCS_to_* perl scripts. For consistency, use "$hashref->{key}" style everywhere. Kyotaro Horiguchi Discussion: https://www.postgresql.org/message-id/20170130.153738.139030994.horiguchi.kyot...@lab.ntt.co.jp http://git.postgresql.org/pg/commitdiff/bc1686f3f653d30847736f2b71d694b98ba5c31d - Don't create "holes" in BufFiles, in the new logtape code. The "Simplify tape block format" commit ignored the rule that blocks returned by ltsGetFreeBlock() must be written out in the same order, at least in the first write pass. To fix, relax that requirement, by making ltsWriteBlock() to detect if it's about to create a "hole" in the underlying BufFile, and fill it with zeros instead. Reported, analysed, and reviewed by Peter Geoghegan. Discussion: https://www.postgresql.org/message-id/cam3swzrwdntkhig0gyix_1muaypik3dv6-6542pye2iel-f...@mail.gmail.com http://git.postgresql.org/pg/commitdiff/7ac4a389a7dbddaa8b19deb228f0a988e79c5795 - Replace isMD5() with a more future-proof way to check if pw is encrypted. The rule is that if pg_authid.rolpassword begins with "md5" and has the right length, it's an MD5 hash, otherwise it's a plaintext password. The idiom has been to use isMD5() to check for that, but that gets awkward, when we add new kinds of verifiers, like the verifiers for SCRAM authentication in the pending SCRAM patch set. Replace isMD5() with a new get_password_type() function, so that when new verifier types are added, we don't need to remember to modify every place that currently calls isMD5(), to also recognize the new kinds of verifiers. Also, use the new plain_crypt_verify function in passwordcheck, so that it doesn't need to know about MD5, or in the future, about other kinds of hashes or password verifiers. Reviewed by Michael Paquier and Peter Eisentraut. Discussion: https://www.postgresql.org/message-id/2d07165c-1793-e243-a2a9-e45b624c7...@iki.fi http://git.postgresql.org/pg/commitdiff/dbd69118c05d73969a1bd52ead6702c6e40b0fee - Silence compiler warning. Not all compilers understand that the elog(ERROR) never returns. David Rowley http://git.postgresql.org/pg/commitdiff/cb695ae993a38a0600a907154cfcc71285a9b9ef - Add KOI8-U map files to Makefile. These were left out by mistake back when support for KOI8-U encoding was added. Extracted from Kyotaro Horiguchi's larger patch. http://git.postgresql.org/pg/commitdiff/53dd2da257fb5904b087b97dd9c2867390d309c1 Tom Lane pushed: - Update time zone data files to tzdata release 2016j. DST law changes in northern Cyprus (new zone Asia/Famagusta), Russia (new zone Europe/Saratov), Tonga, Antarctica/Casey. Historical corrections for Asia/Aqtau, Asia/Atyrau, Asia/Gaza, Asia/Hebron, Italy, Malta. Replace invented zone abbreviation "TOT" for Tonga with numeric UTC offset; but as in the past, we'll keep accepting "TOT" for input. http://git.postgresql.org/pg/commitdiff/308d8682740391cf6e94fdbadcdbbecfa02ea208 - Make psql reject attempts to set special variables to invalid values. Previously, if the user set a special variable such as ECHO to an unrecognized value, psql would bleat but store the new value anyway, and then fall back to a default setting for the behavior controlled by the variable. This was agreed to be a not particularly good idea. With this patch, invalid values result in an error message and no change in state. (But this applies only to variables that affect psql's behavior; purely informational variables such as ENCODING can still be set to random values.) To do this, modify the API for psql's assign-hook functions so that they can return an OK/not OK result, and give them the responsibility for printing error messages when they reject a value. Adjust the APIs for ParseVariableBool and ParseVariableNum to support the new behavior conveniently. In passing, document the variable VERSION, which had somehow escaped that. And improve the quite-inadequate commenting in psql/variables.c. Daniel Vérité, reviewed by Rahila Syed, some further tweaking by me Discussion: https://postgr.es/m/7356e741-fa59-4146-a8eb-cf95fd6b21fb@mm http://git.postgresql.org/pg/commitdiff/511ae628f31b4e791cd5c7836e46cb84dcf145fd - Add a regression test script dedicated to exercising system views. Quite a few of our built-in system views were not exercised anywhere in the regression tests. This is perhaps not so exciting for the ones that are simple projections/joins of system catalogs, but for the ones that are wrappers for set-returning C functions, the omission translates directly to lack of test coverage for those functions. In many cases, the reason for the omission is that the view doesn't have much to do with any specific SQL feature, so there's no natural place to test it. To remedy that, invent a new script sysviews.sql that's dedicated to testing SRF-based views. Move a couple of tests that did fit this charter into the new script, and add simple "count(*)" based tests of other views within the charter. That's enough to ensure we at least exercise the main code path through the SRF, although it does little to prove that the output is sane. More could be done here, no doubt, and I hope someone will think about how we can test these views more thoroughly. But this is a starting point. Discussion: https://postgr.es/m/19359.1485723...@sss.pgh.pa.us http://git.postgresql.org/pg/commitdiff/d002f16c6ec38f76d1ee97367ba6af3000d441d0 - Invent pg_hba_file_rules view to show the content of pg_hba.conf. This view is designed along the same lines as pg_file_settings, to wit it shows what is currently in the file, not what the postmaster has loaded as the active settings. That allows it to be used to pre-vet edits before issuing SIGHUP. As with the earlier view, go out of our way to allow errors in the file to be reflected in the view, to assist that use-case. (We might at some point invent a view to show the current active settings, but this is not that patch; and it's not trivial to do.) Haribabu Kommi, reviewed by Ashutosh Bapat, Michael Paquier, Simon Riggs, and myself Discussion: https://postgr.es/m/cajrrpgerh4jiwpcxt1-46qxudmnp2qdrg9+-tek_xc8aphs...@mail.gmail.com http://git.postgresql.org/pg/commitdiff/de16ab7238888b16825ad13f0bbe123632915e9b - Simplify some long-obsolete code in hba.c's next_token(). next_token() oddly set its buffer space consumption limit to one before the last char position in the buffer, not the last as you'd expect. The reason is there was once an ugly kluge to mark keywords by appending a newline to them, potentially requiring one more byte. Commit e5e2fc842 removed that kluge, but failed to notice that the length limit could be increased. Also, remove some vestigial handling of newline characters in the buffer. That was left over from when this function read the file directly using getc(). Commit 7f49a67f9 changed it to read from a buffer, from which tokenize_file had already removed the only possible occurrence of newline, but did not simplify this function in consequence. Also, ensure that we don't return with *lineptr set to someplace past the terminating '\0'; that would be catastrophic if a caller were to ask for another token from the same line. This is just latent since no callers actually do call again after a "false" return; but considering that it was actually costing us extra code to do it wrong, we might as well make it bulletproof. Noted while reviewing pg_hba_file_rules patch. http://git.postgresql.org/pg/commitdiff/1e5a5d03da14ba9b734c6a2a1a822dcd8af110eb - Make psql's \set display variables in alphabetical order. "\set" with no arguments displays all defined variables, but it does so in the order that they appear in variables.c's list, which previously was mostly creation order. That makes the list ugly and hard to find things in, and it exposes some psql implementation details to users. (For instance, ordinary variables will move to the bottom of the list if unset and set again, but variables that have hooks won't.) Fix that by keeping the list in alphabetical order at all times, which isn't much more complicated than breaking out of the insertion search loops once we reach an entry that should be after the one to be inserted. Discussion: https://postgr.es/m/31785.1485900...@sss.pgh.pa.us http://git.postgresql.org/pg/commitdiff/c3e3844a92fe42109e4106314f7d229f784a7d0a - Improve psql's behavior for \set and \unset of its control variables. This commit improves on the results of commit 511ae628f in two ways: 1. It restores the historical behavior that "\set FOO" is interpreted as setting FOO to "on", if FOO is a boolean control variable. We already found one test script that was expecting that behavior, and the psql documentation certainly does nothing to discourage people from assuming that would work, since it often says just "if FOO is set" when describing the effects of a boolean variable. However, now this case will result in actually setting FOO to "on", not an empty string. 2. It arranges for an "\unset" of a control variable to set the value back to its default value, rather than becoming apparently undefined. The control variables are also initialized that way at psql startup. In combination, these things guarantee that a control variable always has a displayable value that reflects what psql is actually doing. That is a pretty substantial usability improvement. The implementation involves adding a second type of variable hook function that is able to replace a proposed new value (including NULL) with another one. We could alternatively have complicated the API of the assign hook, but this way seems better since many variables can share the same substitution hook function. Also document the actual behavior of these variables more fully, including covering assorted behaviors that were there before but never documented. This patch also includes some minor cleanup that should have been in 511ae628f but was missed. Patch by me, but it owes a lot to discussions with Daniel Vérité. Discussion: https://postgr.es/m/9572.1485821...@sss.pgh.pa.us http://git.postgresql.org/pg/commitdiff/86322dc7e013b4062393dcbb74043db003e23ec5 - Provide CatalogTupleDelete() as a wrapper around simple_heap_delete(). This extends the work done in commit 2f5c9d9c9 to provide a more nearly complete abstraction layer hiding the details of index updating for catalog changes. That commit only invented abstractions for catalog inserts and updates, leaving nearby code for catalog deletes still calling the heap-level routines directly. That seems rather ugly from here, and it does little to help if we ever want to shift to a storage system in which indexing work is needed at delete time. Hence, create a wrapper function CatalogTupleDelete(), and replace calls of simple_heap_delete() on catalog tuples with it. There are now very few direct calls of [simple_]heap_delete remaining in the tree. Discussion: https://postgr.es/m/462.1485902...@sss.pgh.pa.us http://git.postgresql.org/pg/commitdiff/ab02896510e26e46b830c87eef2c03dd3c52c09e - Fix CatalogTupleInsert/Update abstraction for case of shared indstate. Add CatalogTupleInsertWithInfo and CatalogTupleUpdateWithInfo to let callers use the CatalogTupleXXX abstraction layer even in cases where we want to share the results of CatalogOpenIndexes across multiple inserts/updates for efficiency. This finishes the job begun in commit 2f5c9d9c9, by allowing some remaining simple_heap_insert/update calls to be replaced. The abstraction layer is now complete enough that we don't have to export CatalogIndexInsert at all anymore. Also, this fixes several places in which 2f5c9d9c9 introduced performance regressions by using retail CatalogTupleInsert or CatalogTupleUpdate even though the previous coding had been able to amortize CatalogOpenIndexes work across multiple tuples. A possible future improvement is to arrange for the indexing.c functions to cache the CatalogIndexState somewhere, maybe in the relcache, in which case we could get rid of CatalogTupleInsertWithInfo and CatalogTupleUpdateWithInfo again. But that's a task for another day. Discussion: https://postgr.es/m/27502.1485981...@sss.pgh.pa.us http://git.postgresql.org/pg/commitdiff/aedd554f84bb3cedb32e6e2a954a70537a4da6b9 - Fix mishandling of tSRFs at different nesting levels. Given a targetlist like "srf(x), f(srf(x))", split_pathtarget_at_srfs() decided that it needed two levels of ProjectSet nodes, failing to notice that the two SRF calls are textually equal(). Because of that, setrefs.c would convert the upper ProjectSet's tlist to "Var1, f(Var1)" (where Var1 represents a reference to the srf(x) output of the lower ProjectSet). This triggered an assertion in nodeProjectSet.c complaining that it found no SRFs to evaluate, as reported by Erik Rijkers. What we want in such a case is to evaluate srf(x) only once and use a plain Result node to compute "Var1, f(Var1)"; that gives results similar to what previous versions produced, whereas allowing srf(x) to be evaluated again in an upper ProjectSet would square the number of rows emitted. Furthermore, even if the SRF calls aren't textually identical, we want them to be evaluated in lockstep, because that's what happened in the old implementation. But split_pathtarget_at_srfs() got this completely wrong, using two levels of ProjectSet for a case like "srf(x), f(srf(y))". Hence, rewrite split_pathtarget_at_srfs() from the ground up so that it groups SRFs according to the depth of nesting of SRFs in their arguments. This is pretty much how we envisioned that working originally, but I blew it when it came to implementation. In passing, optimize the case of target == input_target, which I noticed is not only possible but quite common. Discussion: https://postgr.es/m/dcbd2853c05d22088766553d60dc7...@xs4all.nl http://git.postgresql.org/pg/commitdiff/c82d4e658eff287846fe6243966d110ff4ae9025 - Fix placement of initPlans when forcibly materializing a subplan. If we forcibly place a Material node atop a finished subplan, we need to move any initPlans attached to the subplan up to the Material node, in order to keep SS_finalize_plan() happy. I'd figured this out in commit 7b67a0a49 for the case of materializing a cursor plan, but out of an abundance of caution, I put the initPlan movement hack at the call site for that case, rather than inside materialize_finished_plan(). That was the wrong thing, because it turns out to also be necessary for the only other caller of materialize_finished_plan(), ie subselect.c. We lacked any test cases that exposed the mistake, but bug#14524 from Wei Congrui shows that it's possible to get an initPlan reference into the top tlist in that case too, and then SS_finalize_plan() complains. Hence, move the hack into materialize_finished_plan(). In HEAD, also relocate some recently-added tests in subselect.sql, which I'd unthinkingly dropped into the middle of a sequence of related tests. Report: https://postgr.es/m/20170202060020.1400.89...@wrigleys.postgresql.org http://git.postgresql.org/pg/commitdiff/555494d1bc119173bbf712940da823303644d4de - Avoid improbable null pointer dereference in pgpassfileWarning(). Coverity complained that we might pass a null pointer to strcmp() if PQresultErrorField were to return NULL. That shouldn't be possible, since the server is supposed to always provide some SQLSTATE or other in an error message. But we usually defend against such hazards, and it only takes a little more code to do so here. There's no good reason to think this is a live bug, so no back-patch. http://git.postgresql.org/pg/commitdiff/8ac0365c22f20dcd2a6b6752b95b665ada83e858 - Clean up psql's behavior for a few more control variables. Modify FETCH_COUNT to always have a defined value, like other control variables, mainly so it will always appear in "\set" output. Add hooks to force HISTSIZE to be defined and require it to have an integer value. (I don't see any point in allowing it to be set to non-integral values.) Add hooks to force IGNOREEOF to be defined and require it to have an integer value. Unlike the other cases, here we're trying to be bug-compatible with a rather bogus externally-defined behavior, so I think we need to continue to allow "\set IGNOREEOF whatever". Fix it so that the substitution hook silently replace non-numeric values with "10", so that the stored value always reflects what we're really doing. Add a dummy assign hook for HISTFILE, just so it's always in variables.c's list. We can't require it to be defined always, because that would break the interaction with the PSQL_HISTORY environment variable, so there isn't any change in visible behavior here. Remove tab-complete.c's private list of known variable names, since that's really a maintenance nuisance. Given the preceding changes, there are no control variables it won't show anyway. This does mean that if for some reason you've unset one of the status variables (DBNAME, HOST, etc), that variable would not appear in tab completion for \set. But I think that's fine, for at least two reasons: we shouldn't be encouraging people to use those variables as regular variables, and if someone does do so anyway, why shouldn't it act just like a regular variable? Remove ugly and no-longer-used-anywhere GetVariableNum(). In general, future additions of integer-valued control variables should follow the paradigm of adding an assign hook using ParseVariableNum(), so there's no reason to expect we'd need this again later. Discussion: https://postgr.es/m/17516.1485973...@sss.pgh.pa.us http://git.postgresql.org/pg/commitdiff/fd6cd698031d3dbeccafde49a8b118cb840312aa - Fix a bunch more portability bugs in commit 08bf6e529. It seems like somebody used a dartboard while choosing integer widths for the various values taken and returned by these functions ... and then threw a fresh set of darts while writing the SQL declarations. This patch brings the C code into line with what the SQL declarations say, which is enough to make it not dump core on the particular 32-bit machine I'm testing on. But I think we could do with another round of looking at what the datum widths *should* be. For instance, it's not all that sensible that hash_bitmap_info decided to use int64 to represent a BlockNumber input when get_raw_page doesn't do it that way. There's also a remaining problem that the expected outputs from the test script are platform-dependent, but I'll leave that issue for somebody else. Per buildfarm. http://git.postgresql.org/pg/commitdiff/c6eeb67dcc3b3f7aa94335e18a1075863d808a7c - In pageinspect/hashfuncs.c, avoid crashes on alignment-picky machines. On machines with MAXALIGN = 8, the payload of a bytea is not maxaligned, since it will start 4 bytes into a palloc'd value. On alignment-picky hardware, this will cause failures in accesses to 8-byte-wide values within the page. We already encountered this problem when we introduced GIN index inspection functions, and fixed it in commit 84ad68d64. Make use of the same function for hash indexes. A small difficulty is that up to now contrib/pageinspect has not shared any functions at all across files. To support that, introduce a common header file "pageinspect.h" for the module. Also, move get_page_from_raw() out of ginfuncs.c, where it didn't especially belong, and put it in rawpage.c which seems a more natural home. Per buildfarm. Discussion: https://postgr.es/m/17311.1486134...@sss.pgh.pa.us http://git.postgresql.org/pg/commitdiff/14e9b18fed289e483ed28daec60fdab95da9cc48 - First-draft release notes for 9.6.2. 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/9863017b87f3592ff663d03fc663a4f1f8fdb8b2 Peter Eisentraut pushed: - Additional test coverage for sequences. Reviewed-by: Michael Paquier <michael.paqu...@gmail.com> http://git.postgresql.org/pg/commitdiff/d711532b2eb70cf2f56d95efcc608d474266d769 - Fix sequence test in cs_CZ locale. Rename some objects so that sorted output becomes less locale-dependent. http://git.postgresql.org/pg/commitdiff/46aae5949f56580281a0f487c785c745d8856a04 - doc: Document result set of CREATE_REPLICATION_SLOT. From: Marko Tiikkaja <ma...@joh.to> http://git.postgresql.org/pg/commitdiff/ecb814b5cef4971e50ee177eff320d416aa0b882 - doc: Add missing include in example code. It's not broken because the header file is included via other headers, but for better style we should be more explicit. Reported-by: mthrockmor...@hme.com http://git.postgresql.org/pg/commitdiff/aa09b9dcd57cbf18516332bf8310c12ef6f83715 Álvaro Herrera pushed: - Tweak catalog indexing abstraction for upcoming WARM. Split the existing CatalogUpdateIndexes into two different routines, CatalogTupleInsert and CatalogTupleUpdate, which do both the heap insert/update plus the index update. This removes over 300 lines of boilerplate code all over src/backend/catalog/ and src/backend/commands. The resulting code is much more pleasing to the eye. Also, by encapsulating what happens in detail during an UPDATE, this facilitates the upcoming WARM patch, which is going to add a few more lines to the update case making the boilerplate even more boring. The original CatalogUpdateIndexes is removed; there was only one use left, and since it's just three lines, we can as well expand it in place there. We could keep it, but WARM is going to break all the UPDATE out-of-core callsites anyway, so there seems to be no benefit in doing so. Author: Pavan Deolasee Discussion: https://www.postgr.es/m/CABOikdOcFYSZ4vA2gYfs=m2cdxzxx4qgheeiw3fu9pcfkhl...@mail.gmail.com http://git.postgresql.org/pg/commitdiff/2f5c9d9c9cec436e55847ec580606d7e88067df6 Robert Haas pushed: - Move comment about test slightly closer to test. The addition of a TestForOldSnapshot() call here has made the referent of this comment slightly less clear, so move the comment to compensate. Amit Kapila (as part of the parallel index scan patch) http://git.postgresql.org/pg/commitdiff/8a815e3fc318b441a5e8a37e4129660d81e1e012 - Refactor other replication commands to use DestRemoteSimple. Commit a84069d9350400c860d5e932b50dfd337aa407b0 added a new type of DestReceiver to avoid duplicating the existing code for the SHOW command, but it turns out we can leverage that new DestReceiver type in a few more places, saving some code. Michael Paquier, reviewed by Andres Freund and by me. Discussion: http://postgr.es/m/CAB7nPqSdFOQC0evc0r1nJeQyGBqjBrR41MC4rcMqUUpoJaZbtQ%40mail.gmail.com Discussion: http://postgr.es/m/cab7npqt2k4xft1jgquffbjsoc-nukxg5qbduchpmbk6xi1k...@mail.gmail.com http://git.postgresql.org/pg/commitdiff/bbd8550bce146f86e5e883f1232292a975c314fb - Increase upper bound for bgwriter_lru_maxpages. There is no particularly good reason to limit this value to 1000, so increase the limit to INT_MAX / 2, the same limit we use for shared_buffers. It's not clear how much practical effect larger settings will have, but there seems no harm in letting people try it. Jim Nasby, less a comment change I stripped out. Discussion: http://postgr.es/m/f6e58a22-030b-eb8a-5457-f62fb08d7...@bluetreble.com http://git.postgresql.org/pg/commitdiff/14ca9abfbe4643408ad6ed3279f2f6366cafb3f1 - pageinspect: Support hash indexes. Patch by Jesper Pedersen and Ashutosh Sharma, with some error handling improvements by me. Tests from Peter Eisentraut. Reviewed by Álvaro Herrera, Michael Paquier, Jesper Pedersen, Jeff Janes, Peter Eisentraut, Amit Kapila, Mithun Cy, and me. Discussion: http://postgr.es/m/e2ac6c58-b93f-9dd9-f4e6-d6d30add7...@redhat.com http://git.postgresql.org/pg/commitdiff/08bf6e529587e1e9075d013d859af2649c32a511 - pageinspect: Try to fix some bugs in previous commit. Commit 08bf6e529587e1e9075d013d859af2649c32a511 seems not to have used the correct *GetDatum and PG_GETARG_* macros for the SQL types in some cases, and some of the SQL types seem to have been poorly chosen, too. Try to fix it. I'm not sure if this is the reason why the buildfarm is currently unhappy with this code, but it seems like a good place to start. Buildfarm unhappiness reported by Tom Lane. http://git.postgresql.org/pg/commitdiff/ed807fda6d5102537daa5d725e716555cbc49f44 - pageinspect: Remove platform-dependent values from hash tests. Per a report from Tom Lane, the ffactor reported by hash_metapage_info and the free_size reported by hash_page_stats vary by platform. Ashutosh Sharma and Robert Haas http://git.postgresql.org/pg/commitdiff/29e312bc1301061ae9f897ff39f3b230c421a5fb - pgstattuple: Add pgstathashindex. Since pgstattuple v1.5 hasn't been released yet, no need for a new extension version. The new function exposes statistics about hash indexes similar to what other pgstatindex functions return for other index types. Ashutosh Sharma, reviewed by Kuntal Ghosh. Substantial further revisions by me. http://git.postgresql.org/pg/commitdiff/e759854a09d49725a9519c48a0d71a32bab05a01 - pageinspect: More type-sanity surgery on the new hash index code. Uniformly expose unsigned quantities using the next-wider signed integer type (since we have no unsigned types at the SQL level). At the SQL level, this results a change to report itemoffset as int4 rather than int2. Also at the SQL level, report one value that is an OID as type oid. Under the hood, uniformly use macros that match the SQL output type as to both width and signedness. http://git.postgresql.org/pg/commitdiff/871ec0e33673ad9719760131b71a02ecbda82e12 - Improve grammar of message about two-phase state files. When there's only one two-phase state file, there's also only one long-running prepared transaction. Adjust the message text accordingly. Nikhil Sontakke Discussion: http://postgr.es/m/CAMGcDxcmR_DWZXXndGoPzVQx=B17A5=RviEA1qNaF=fwly5...@mail.gmail.com http://git.postgresql.org/pg/commitdiff/38c363adf497c0a05858dc00bc49ea42023bd572 - Remove redundant comment. Rafia Sabih http://git.postgresql.org/pg/commitdiff/6f4b4ceefa673dff6563d2d17e2039248f16fe1d Andrew Dunstan pushed: - Don't count background workers against a user's connection limit. Doing so doesn't seem to be within the purpose of the per user connection limits, and has particularly unfortunate effects in conjunction with parallel queries. Backpatch to 9.6 where parallel queries were introduced. David Rowley, reviewed by Robert Haas and Albe Laurenz. http://git.postgresql.org/pg/commitdiff/f1169ab501ce90e035a7c6489013a1d4c250ac92 Noah Misch pushed: - Code review for avoidance of direct cross-module links. Remove $(pkglibdir) from $(rpathdir), since commits d51924be886c2a05e691fa05b16cb6b30ab8370f and eda04886c1e048d695728206504ab4198462168e removed direct linkage to objects stored there. Users are unlikely to notice the difference. Accompany every $(python_libspec) with $(python_additional_libs); this doesn't fix a demonstrated bug, but it might do so on rare Python configurations. With these changes, AIX ceases to be a special case. http://git.postgresql.org/pg/commitdiff/acd73ad1a17f7aed6a914dd9c331f1043d89988d Fujii Masao pushed: - Be sure to release LogicalRepLauncherLock in DROP SUBSCRIPTION command. Previously DROP SUBSCRIPTION command forgot to release the lock at all. Original patches by Kyotaro Horiguchi and Michael Paquier, but I didn't use them. Discussion: http://postgr.es/m/20170201.173623.66249355.horiguchi.kyot...@lab.ntt.co.jp http://git.postgresql.org/pg/commitdiff/39b8cc991fe31ee8df8b0fee467bbd9800fcc1c5 == Pending Patches == Takayuki Tsunakawa sent in another revision of a patch to support huge pages on Windows. Nikita Glukhov sent in three revisions of a patch to fix a bug in SP-GiST box_ops. Kyotaro HORIGUCHI sent in two more revisions of a patch to implement character conversion with radix trees. Alexander Korotkov sent in another revision of a patch to cacheline align PGXACT. Nikita Glukhov sent in a patch to implement kNN searches for SP-GiST. Michaël Paquier sent in another revision of a patch to allow interrupts on waiting standby. Rushabh Lathia sent in a patch to extend the existing wait event infrastructure to implement the wait events for the disk I/O. Etsuro Fujita sent in another revision of a patch to push down more full joins to the PostgreSQL FDW. Michaël Paquier sent in two more revisions of a patch to refactor replication commands using printsimple. David Rowley sent in two more revisions of a patch to for improve performance for outer joins where outer side is unique. Daisuke Higuchi and Ashutosh Bapat traded patches to fix a bug where PQgetResult is not called until PQgetResult has returned a null pointer. Heikki Linnakangas sent in two more revisions of a patch to fix an issue which produced a deadlock in XLogInsert on AIX. Kyotaro HORIGUCHI sent in another revision of a patch to implement asynchronous execution. Tomas Vondra sent in another revision of a patch to implement multivariate statistics. Amit Kapila sent in two more revisions of a patch to implement parallel index scans. Claudio Freire sent in two more revisions of a patch to enable VACUUM to use more than 1GB of work_mem. Pavan Deolasee, Álvaro Herrera, and Tom Lane traded patches to fix an issue where CREATE INDEX CONCURRENTLY could cause index corruption. Amit Kapila sent in another revision of a patch to parallelize queries containing initplans. Pavel Stěhule sent in another revision of a patch to implement xmltable(). Michaël Paquier sent in a patch to forbid newline and carriage return characters in database and role names, and ensure clean-up of data directory even with restricted path applied. Haribabu Kommi sent in another revision of a patch to add a macaddr 64 bit (EUI-64) datatype. Peter Eisentraut sent in another revision of a patch to implement a set of SEQUENCE data types. Pavan Deolasee sent in three more revisions of a patch to implement WARM. Kyotaro HORIGUCHI sent in two more revisions of a patch to fix a bug in physical replication slots. Kyotaro HORIGUCHI sent in two more revisions of a patch to enable logical replication between databases with different encodings. Dilip Kumar sent in two more revisions of a patch to implement parallel bitmap heap scan. Pavel Stěhule sent in another revision of a patch to enable PL/pgsql to force a custom or generic plan. Anastasia Lubennikova sent in a patch to allow casting from the appropriate jsonb objects to numeric, int, float, bool. Dagfinn Ilmari Mannsåker sent in two revisions of a patch to add tab completion for DEALLOCATE. Rushabh Lathia sent in two more revisions of a patch to implement Gather Merge. Nikhil Sontakke sent in two more revisions of a patch to speed up two-phase transactions. David Rowley sent in a patch to fix a compiler warning in dbd69118. Michaël Paquier sent in two revisions of a patch to provide list of subscriptions and publications in psql's completion. Corey Huinker sent in three more revisions of a patch to add \if and friends to psql. Peter Moser sent in another revision of a patch to add temporal query primitives. Alexey Bashtanov sent in a patch to optimize the query used to produce information_schema.constraint_column_usage. Simon Riggs sent in a patch to introduce the concept of a "superowner". Andres Freund sent in a patch to implement a basic lockless single producer, multiple consumer ringbuffer, and a rewrite of the bgwriter to use same. Kyotaro HORIGUCHI sent in another revision of a patch to refactor tab completion in psql and use same to add some tab completion features. Amit Langote sent in a patch to improve the documentation about partitioned tables. Andreas Karlsson sent in a patch to add psql tab completion for \help DROP|ALTER. Alexander Korotkov sent in a patch to implement low-level locking on PowerPC in assembly. Boris Muratshin sent in a patch to implement 3D Z-curve spatial indexes. Fabien COELHO sent in another revision of a patch to add more operators and functions to pgbench. Alexander Korotkov sent in a patch to re-add strategy to PinBuffer. Masahiko Sawada sent in a patch to fix a typo in a variable name in launcher.c. Noah Misch sent in a patch to ignore tablespace ACLs when ignoring schema ACLs. Brandur Leach sent in another revision of a patch to implement SortSupport for macaddr data type. -- Sent via pgsql-announce mailing list (pgsql-announce@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-announce
