commit : 1ad47d574e31f3bbe47bc015b2e04b42f55a582c author : Tom Lane <email@example.com> date : Mon, 8 May 2017 17:22:52 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 8 May 2017 17:22:52 -0400
Last-minute updates for release notes.
commit : 89cd44cc50d3d82dc6f001ac357bedd96b8387d8 author : Tom Lane <email@example.com> date : Mon, 8 May 2017 12:57:28 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 8 May 2017 12:57:28 -0400
Security: CVE-2017-7484, CVE-2017-7485, CVE-2017-7486
Match pg_user_mappings limits to information_schema.user_mapping_options.
commit : 99cbb0bd9abc4c3b85a2de2f2e83b5ddc5d38d35 author : Noah Misch <email@example.com> date : Mon, 8 May 2017 07:24:24 -0700 committer: Noah Misch <firstname.lastname@example.org> date : Mon, 8 May 2017 07:24:24 -0700
Both views replace the umoptions field with NULL when the user does not meet qualifications to see it. They used different qualifications, and pg_user_mappings documented qualifications did not match its implemented qualifications. Make its documentation and implementation match those of user_mapping_options. One might argue for stronger qualifications, but these have long, documented tenure. pg_user_mappings has always exhibited this problem, so back-patch to 9.2 (all supported versions). Michael Paquier and Feike Steenbergen. Reviewed by Jeff Janes. Reported by Andrew Wheelwright. Security: CVE-2017-7486
Add detail to PGREQUIRESSL documentation.
commit : 47864be33ccfd8b7334692871fd098596be318e9 author : Noah Misch <email@example.com> date : Mon, 8 May 2017 07:24:28 -0700 committer: Noah Misch <firstname.lastname@example.org> date : Mon, 8 May 2017 07:24:28 -0700
commit : 7f7d69e0d53651ba9039cfbaace0528f77b7c3cf author : Peter Eisentraut <email@example.com> date : Mon, 8 May 2017 10:20:30 -0400 committer: Peter Eisentraut <firstname.lastname@example.org> date : Mon, 8 May 2017 10:20:30 -0400
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 8d661e2d2c9694859556e86c90a6aa7030d0150f
Add security checks to selectivity estimation functions
commit : d035c1b970fe948c10773315a2f022204bc45df6 author : Peter Eisentraut <email@example.com> date : Fri, 5 May 2017 12:18:48 -0400 committer: Peter Eisentraut <firstname.lastname@example.org> date : Fri, 5 May 2017 12:18:48 -0400
Some selectivity estimation functions run user-supplied operators over data obtained from pg_statistic without security checks, which allows those operators to leak pg_statistic data without having privileges on the underlying tables. Fix by checking that one of the following is satisfied: (1) the user has table or column privileges on the table underlying the pg_statistic data, or (2) the function implementing the user-supplied operator is leak-proof. If neither is satisfied, planning will proceed as if there are no statistics available. At least one of these is satisfied in most cases in practice. The only situations that are negatively impacted are user-defined or not-leak-proof operators on a security-barrier view. Reported-by: Robert Haas <email@example.com> Author: Peter Eisentraut <firstname.lastname@example.org> Author: Tom Lane <email@example.com> Security: CVE-2017-7484
Release notes for 9.6.3, 9.5.7, 9.4.12, 9.3.17, 9.2.21.
commit : f79531ffd42f2d0e5c35d1dffbc2c2f2cd2086dc author : Tom Lane <firstname.lastname@example.org> date : Sun, 7 May 2017 16:56:03 -0400 committer: Tom Lane <email@example.com> date : Sun, 7 May 2017 16:56:03 -0400
Guard against null t->tm_zone in strftime.c.
commit : da55df018ab196819f275c1fb37e7f3fe20cb564 author : Tom Lane <firstname.lastname@example.org> date : Sun, 7 May 2017 12:33:12 -0400 committer: Tom Lane <email@example.com> date : Sun, 7 May 2017 12:33:12 -0400
The upstream IANA code does not guard against null TM_ZONE pointers in this function, but in our code there is such a check in the other pre-existing use of t->tm_zone. We do have some places that set pg_tm.tm_zone to NULL. I'm not entirely sure it's possible to reach strftime with such a value, but I'm not sure it isn't either, so be safe. Per Coverity complaint.
Install the "posixrules" timezone link in MSVC builds.
commit : 82e7d3dfd17fc17738a1eb35d1b45677b66a88f5 author : Tom Lane <firstname.lastname@example.org> date : Sun, 7 May 2017 11:57:41 -0400 committer: Tom Lane <email@example.com> date : Sun, 7 May 2017 11:57:41 -0400
Somehow, we'd missed ever doing this. The consequences aren't too severe: basically, the timezone library would fall back on its hardwired notion of the DST transition dates to use for a POSIX-style zone name, rather than obeying US/Eastern which is the intended behavior. The net effect would only be to obey current US DST law further back than it ought to apply; so it's not real surprising that nobody noticed. David Rowley, per report from Amit Kapila Discussion: https://postgr.es/m/CAA4eK1LC7CaNhRAQ__C3ht1JVrPzaAXXhEJRnR5L6bfYHiLmWw@mail.gmail.com
Restore fullname contents before falling through in pg_open_tzfile().
commit : 9061680f06b06588281bdc8e59106eb33726360f author : Tom Lane <firstname.lastname@example.org> date : Sun, 7 May 2017 11:34:31 -0400 committer: Tom Lane <email@example.com> date : Sun, 7 May 2017 11:34:31 -0400
Fix oversight in commit af2c5aa88: if the shortcut open() doesn't work, we need to reset fullname to be just the name of the toplevel tzdata directory before we fall through into the pre-existing code. This failed to be exposed in my (tgl's) testing because the fall-through path is actually never taken under normal circumstances. David Rowley, per report from Amit Kapila Discussion: https://postgr.es/m/CAA4eK1LC7CaNhRAQ__C3ht1JVrPzaAXXhEJRnR5L6bfYHiLmWw@mail.gmail.com
commit : fea56cd4d0f8d2e848fe291aca382d9e1c9eca39 author : Tom Lane <firstname.lastname@example.org> date : Sat, 6 May 2017 14:19:47 -0400 committer: Tom Lane <email@example.com> date : Sat, 6 May 2017 14:19:47 -0400
This system function has been there a very long time, but somehow escaped being listed in func.sgml. Fabien Coelho and Tom Lane Discussion: https://postgr.es/m/alpine.DEB.2.20.1705061027580.3896@lancre
Allow MSVC to build with Tcl 8.6.
commit : 992e581bff3b0984e23d3fae5e9bed62a5d226fd author : Alvaro Herrera <firstname.lastname@example.org> date : Fri, 5 May 2017 12:05:34 -0300 committer: Alvaro Herrera <email@example.com> date : Fri, 5 May 2017 12:05:34 -0300
Commit eaba54c20c5 added support for Tcl 8.6 for configure-supported platforms after verifying that pltcl works without further changes, but the MSVC tooling wasn't updated accordingly. Update MSVC to match, restructuring the code to avoid duplicating the logic for every Tcl version supported. Backpatch to all live branches, like eaba54c20c5. In 9.4 and previous, change the patch to use backslashes rather than forward, as in the rest of the file. Reported by Paresh More, who also tested the patch I provided. Discussion: https://postgr.es/m/CAAgiCNGVw3ssBtSi3ZNstrz5k00ax=UV+_ZEHUeW_LMSGL2sew@mail.gmail.com
Give nicer error message when connecting to a v10 server requiring SCRAM.
commit : 33356ad68d5d3dce4c234d96dc908d3ca3329e77 author : Heikki Linnakangas <firstname.lastname@example.org> date : Fri, 5 May 2017 11:24:02 +0300 committer: Heikki Linnakangas <email@example.com> date : Fri, 5 May 2017 11:24:02 +0300
This is just to give the user a hint that they need to upgrade, if they try to connect to a v10 server that uses SCRAM authentication, with an older client. Commit to all stable branches, but not master. Discussion: https://firstname.lastname@example.org
Fix cursor_to_xml in tableforest false mode
commit : a48d47908337ce3a17da37e413f1e2ea658552f9 author : Peter Eisentraut <email@example.com> date : Wed, 3 May 2017 21:25:01 -0400 committer: Peter Eisentraut <firstname.lastname@example.org> date : Wed, 3 May 2017 21:25:01 -0400
It only produced <row> elements but no wrapping <table> element. By contrast, cursor_to_xmlschema produced a schema that is now correct but did not previously match the XML data produced by cursor_to_xml. In passing, also fix a minor misunderstanding about moving cursors in the tests related to this. Reported-by: email@example.com Based-on-patch-by: Thomas Munro <firstname.lastname@example.org>
Improve performance of timezone loading, especially pg_timezone_names view.
commit : 1b6db75ef2d1fe96a9cbd643befa2aa7a9b8d933 author : Tom Lane <email@example.com> date : Tue, 2 May 2017 21:50:35 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Tue, 2 May 2017 21:50:35 -0400
tzparse() would attempt to load the "posixrules" timezone database file on each call. That might seem like it would only be an issue when selecting a POSIX-style zone name rather than a zone defined in the timezone database, but it turns out that each zone definition file contains a POSIX-style zone string and tzload() will call tzparse() to parse that. Thus, when scanning the whole timezone file tree as we do in the pg_timezone_names view, "posixrules" was read repetitively for each zone definition file. Fix that by caching the file on first use within any given process. (We cache other zone definitions for the life of the process, so there seems little reason not to cache this one as well.) This probably won't help much in processes that never run pg_timezone_names, but even one additional SET of the timezone GUC would come out ahead. An even worse problem for pg_timezone_names is that pg_open_tzfile() has an inefficient way of identifying the canonical case of a zone name: it basically re-descends the directory tree to the zone file. That's not awful for an individual "SET timezone" operation, but it's pretty horrid when we're inspecting every zone in the database. And it's pointless too because we already know the canonical spelling, having just read it from the filesystem. Fix by teaching pg_open_tzfile() to avoid the directory search if it's not asked for the canonical name, and backfilling the proper result in pg_tzenumerate_next(). In combination these changes seem to make the pg_timezone_names view about 3x faster to read, for me. Since a scan of pg_timezone_names has up to now been one of the slowest queries in the regression tests, this should help some little bit for buildfarm cycle times. Back-patch to all supported branches, not so much because it's likely that users will care much about the view's performance as because tracking changes in the upstream IANA timezone code is really painful if we don't keep all the branches in sync. Discussion: https://email@example.com
Ensure commands in extension scripts see the results of preceding DDL.
commit : c9d6c564f4b1097846f5810a0ae2b8f6123f9467 author : Tom Lane <firstname.lastname@example.org> date : Tue, 2 May 2017 18:05:54 -0400 committer: Tom Lane <email@example.com> date : Tue, 2 May 2017 18:05:54 -0400
Due to a missing CommandCounterIncrement() call, parsing of a non-utility command in an extension script would not see the effects of the immediately preceding DDL command, unless that command's execution ends with CommandCounterIncrement() internally ... which some do but many don't. Report by Philippe Beaudoin, diagnosis by Julien Rouhaud. Rather remarkably, this bug has evaded detection since extensions were invented, so back-patch to all supported branches. Discussion: https://firstname.lastname@example.org
Update time zone data files to tzdata release 2017b.
commit : c96ccc40e41028baff770a1f537059dda4bd76b3 author : Tom Lane <email@example.com> date : Mon, 1 May 2017 11:52:59 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 1 May 2017 11:52:59 -0400
DST law changes in Chile, Haiti, and Mongolia. Historical corrections for Ecuador, Kazakhstan, Liberia, and Spain. The IANA crew continue their campaign to replace invented time zone abbrevations with numeric GMT offsets. This update changes numerous zones in South America, the Pacific and Indian oceans, and some Asian and Middle Eastern zones. I kept these abbreviations in the tznames/ data files, however, so that we will still accept them for input. (We may want to start trimming those files someday, but I think we should wait for the upstream dust to settle before deciding what to do.) In passing, add MESZ (Mitteleuropaeische Sommerzeit) to the tznames lists; since we accept MEZ (Mitteleuropaeische Zeit) it seems rather strange not to take the other one. And fix some incorrect, or at least obsolete, comments that certain abbreviations are not traceable to the IANA data.
Sync our copy of the timezone library with IANA release tzcode2017b.
commit : 54aeb8d3e7c4f79c7dad1c255d9a509f8db83bf3 author : Tom Lane <email@example.com> date : Sun, 30 Apr 2017 15:13:51 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Sun, 30 Apr 2017 15:13:51 -0400
zic no longer mishandles some transitions in January 2038 when it attempts to work around Qt bug 53071. This fixes a bug affecting Pacific/Tongatapu that was introduced in zic 2016e. localtime.c now contains a workaround, useful when loading a file generated by a buggy zic. There are assorted cosmetic changes as well, notably relocation of a bunch of #defines.
Fix VALIDATE CONSTRAINT to consider NO INHERIT attribute.
commit : f60f0c8fe3d871c8903b487734fd593313b16306 author : Robert Haas <email@example.com> date : Fri, 28 Apr 2017 14:48:38 -0400 committer: Robert Haas <firstname.lastname@example.org> date : Fri, 28 Apr 2017 14:48:38 -0400
Currently, trying to validate a NO INHERIT constraint on the parent will search for the constraint in child tables (where it is not supposed to exist), wrongly causing a "constraint does not exist" error. Amit Langote, per a report from Hans Buschmann. Discussion: http://email@example.com
Fix order of arguments to SubTransSetParent().
commit : 952e33b052758a7febfb2625bf6b0c0f8c660a2b author : Tom Lane <firstname.lastname@example.org> date : Sun, 23 Apr 2017 13:10:58 -0400 committer: Tom Lane <email@example.com> date : Sun, 23 Apr 2017 13:10:58 -0400
ProcessTwoPhaseBuffer (formerly StandbyRecoverPreparedTransactions) mixed up the parent and child XIDs when calling SubTransSetParent to record the transactions' relationship in pg_subtrans. Remarkably, analysis by Simon Riggs suggests that this doesn't lead to visible problems (at least, not in non-Assert builds). That might explain why we'd not noticed it before. Nonetheless, it's surely wrong. This code was born broken, so back-patch to all supported branches. Discussion: https://firstname.lastname@example.org
Avoid depending on non-POSIX behavior of fcntl(2).
commit : ad8fb69cccf47e78d0ddc3e44417867430c5e55c author : Tom Lane <email@example.com> date : Fri, 21 Apr 2017 15:55:56 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Fri, 21 Apr 2017 15:55:56 -0400
The POSIX standard does not say that the success return value for fcntl(F_SETFD) and fcntl(F_SETFL) is zero; it says only that it's not -1. We had several calls that were making the stronger assumption. Adjust them to test specifically for -1 for strict spec compliance. The standard further leaves open the possibility that the O_NONBLOCK flag bit is not the only active one in F_SETFL's argument. Formally, therefore, one ought to get the current flags with F_GETFL and store them back with only the O_NONBLOCK bit changed when trying to change the nonblock state. In port/noblock.c, we were doing the full pushup in pg_set_block but not in pg_set_noblock, which is just weird. Make both of them do it properly, since they have little business making any assumptions about the socket they're handed. The other places where we're issuing F_SETFL are working with FDs we just got from pipe(2), so it's reasonable to assume the FDs' properties are all default, so I didn't bother adding F_GETFL steps there. Also, while pg_set_block deserves some points for trying to do things right, somebody had decided that it'd be even better to cast fcntl's third argument to "long". Which is completely loony, because POSIX clearly says the third argument for an F_SETFL call is "int". Given the lack of field complaints, these missteps apparently are not of significance on any common platforms. But they're still wrong, so back-patch to all supported branches. Discussion: https://email@example.com
Support OpenSSL 1.1.0 in 9.3 and 9.2.
commit : fb50c38e9cb4f4a9953a918664536f3e344ec858 author : Tom Lane <firstname.lastname@example.org> date : Mon, 17 Apr 2017 13:52:42 -0400 committer: Tom Lane <email@example.com> date : Mon, 17 Apr 2017 13:52:42 -0400
This commit back-patches the equivalent of the 9.5-branch commits e2838c580 and 48e5ba61e, so that we can work with OpenSSL 1.1.0 in all supported branches. Original patches by Andreas Karlsson and Heikki Linnakangas, back-patching work by Andreas Karlsson. Patch: https://firstname.lastname@example.org Discussion: https://email@example.com
Back-patch 9.4-era SSL renegotiation code into 9.3 and 9.2.
commit : 58384149bdbd47aab4affb926b32f16a84ef98ce author : Tom Lane <firstname.lastname@example.org> date : Mon, 17 Apr 2017 12:51:40 -0400 committer: Tom Lane <email@example.com> date : Mon, 17 Apr 2017 12:51:40 -0400
This back-patches 9.4 commits 31cf1a1a4, 86029b31e, and 36a3be654 into the prior branches, along with relevant bits of b1aebbb6a and 7ce2a45ae. We had foreseen doing this once the code was proven, but that never did happen, probably because we got sufficiently fed up with renegotiation to disable it by default. However, we have to do something now because the prior code doesn't even compile against OpenSSL 1.1. Per discussion, the best solution seems to be to make the older branches look like 9.4. Discussion: https://firstname.lastname@example.org
Provide a way to control SysV shmem attach address in EXEC_BACKEND builds.
commit : 0d7591c67d685b13dbfcc399cf7fff52ea760c79 author : Tom Lane <email@example.com> date : Sat, 15 Apr 2017 17:27:38 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Sat, 15 Apr 2017 17:27:38 -0400
In standard non-Windows builds, there's no particular reason to care what address the kernel chooses to map the shared memory segment at. However, when building with EXEC_BACKEND, there's a risk that the chosen address won't be available in all child processes. Linux with ASLR enabled (which it is by default) seems particularly at risk because it puts shmem segments into the same area where it maps shared libraries. We can work around that by specifying a mapping address that's outside the range where shared libraries could get mapped. On x86_64 Linux, 0x7e0000000000 seems to work well. This is only meant for testing/debugging purposes, so it doesn't seem necessary to go as far as providing a GUC (or any user-visible documentation, though we might change that later). Instead, it's just controlled by setting an environment variable PG_SHMEM_ADDR to the desired attach address. Back-patch to all supported branches, since the point here is to remove intermittent buildfarm failures on EXEC_BACKEND animals. Owners of affected animals will need to add a suitable setting of PG_SHMEM_ADDR to their build_env configuration. Discussion: https://email@example.com
Improve castNode notation by introducing list-extraction-specific variants.
commit : ba0a0f3ed9e0ef948ea614d16b77f835695ff4da author : Tom Lane <firstname.lastname@example.org> date : Mon, 10 Apr 2017 13:51:29 -0400 committer: Tom Lane <email@example.com> date : Mon, 10 Apr 2017 13:51:29 -0400
This extends the castNode() notation introduced by commit 5bcab1114 to provide, in one step, extraction of a list cell's pointer and coercion to a concrete node type. For example, "lfirst_node(Foo, lc)" is the same as "castNode(Foo, lfirst(lc))". Almost half of the uses of castNode that have appeared so far include a list extraction call, so this is pretty widely useful, and it saves a few more keystrokes compared to the old way. As with the previous patch, back-patch the addition of these macros to pg_list.h, so that the notation will be available when back-patching. Patch by me, after an idea of Andrew Gierth's. Discussion: https://firstname.lastname@example.org
Silence compiler warning in sepgsql
commit : 1d6f5b446fc84d8974087e66d2603ef81387a052 author : Joe Conway <email@example.com> date : Thu, 6 Apr 2017 14:22:01 -0700 committer: Joe Conway <firstname.lastname@example.org> date : Thu, 6 Apr 2017 14:22:01 -0700
<selinux/label.h> includes <stdbool.h>, which creates an incompatible We don't care if <stdbool.h> redefines "true"/"false"; those are close enough. Complaint and initial patch by Mike Palmiotto. Final approach per Tom Lane's suggestion, as discussed on hackers. Backpatching to all supported branches. Discussion: https://postgr.es/m/flat/623bcaae-112e-ced0-8c22-a84f75ae0c53%40joeconway.com
Remove dead code and fix comments in fast-path function handling.
commit : f2389f119f52027a4136c531f29b49a86d3fffc0 author : Heikki Linnakangas <email@example.com> date : Thu, 6 Apr 2017 09:09:39 +0300 committer: Heikki Linnakangas <firstname.lastname@example.org> date : Thu, 6 Apr 2017 09:09:39 +0300
HandleFunctionRequest() is no longer responsible for reading the protocol message from the client, since commit 2b3a8b20c2. Fix the outdated comments. HandleFunctionRequest() now always returns 0, because the code that used to return EOF was moved in 2b3a8b20c2. Therefore, the caller no longer needs to check the return value. Reported by Andres Freund. Backpatch to all supported versions, even though this doesn't have any user-visible effect, to make backporting future patches in this area easier. Discussion: https://email@example.com
Simplify the example of VACUUM in documentation.
commit : 75eea8d7f54b922ab13ac96ab3d751f61c21d487 author : Fujii Masao <firstname.lastname@example.org> date : Fri, 31 Mar 2017 01:31:15 +0900 committer: Fujii Masao <email@example.com> date : Fri, 31 Mar 2017 01:31:15 +0900
Previously a detailed activity report by VACUUM VERBOSE ANALYZE was described as an example of VACUUM in docs. But it had been obsolete for a long time. For example, commit feb4f44d296b88b7f0723f4a4f3945a371276e0b updated the content of that activity report in 2003, but we had forgotten to update the example. So basically we need to update the example. But since no one cared about the details of VACUUM output and complained about that mistake for such long time, per discussion on hackers, we decided to get rid of the detailed activity report from the example and simplify it. Back-patch to all supported versions. Reported by Masahiko Sawada, patch by me. Discussion: https://postgr.es/m/CAD21AoAGA2pB3p-CWmTkxBsbkZS1bcDGBLcYVcvcDxspG_XAfA@mail.gmail.com
Fix unportable disregard of alignment requirements in RADIUS code.
commit : 5fe937f38b493f7c94c4ef8b0940e034afbd78a6 author : Tom Lane <firstname.lastname@example.org> date : Sun, 26 Mar 2017 17:35:35 -0400 committer: Tom Lane <email@example.com> date : Sun, 26 Mar 2017 17:35:35 -0400
The compiler is entitled to store a char local variable with no particular alignment requirement. Our RADIUS code cavalierly took such a local variable and cast its address to a struct type that does have alignment requirements. On an alignment-picky machine this would lead to bus errors. To fix, declare the local variable honestly, and then cast its address to char * for use in the I/O calls. Given the lack of field complaints, there must be very few if any people affected; but nonetheless this is a clear portability issue, so back-patch to all supported branches. Noted while looking at a Coverity complaint in the same code.
Revert Windows service check refactoring, and replace with a different fix.
commit : 8ae3ff64be777b50f560f7cab7c238aae1bde9b0 author : Heikki Linnakangas <firstname.lastname@example.org> date : Fri, 24 Mar 2017 12:39:01 +0200 committer: Heikki Linnakangas <email@example.com> date : Fri, 24 Mar 2017 12:39:01 +0200
This reverts commit 38bdba54a64bacec78e3266f0848b0b4a824132a, "Fix and simplify check for whether we're running as Windows service". It turns out that older versions of MinGW - like that on buildfarm member narwhal - do not support the CheckTokenMembership() function. This replaces the refactoring with a much smaller fix, to add a check for SE_GROUP_ENABLED to pgwin32_is_service(). Only apply to back-branches, and keep the refactoring in HEAD. It's unlikely that anyone is still really using such an old version of MinGW - aside from narwhal - but let's not change the minimum requirements in minor releases. Discussion: https://firstname.lastname@example.org Patch: https://www.postgresql.org/message-id/CAB7nPqSvfu%3DKpJ%3DNX%2BYAHmgAmQdzA7N5h31BjzXeMgczhGCC%2BQ%40mail.gmail.com
doc: Fix a few typos and awkward links
commit : 10a3637eaf9d95c3b8a969a380895ddac1cbbe0f author : Peter Eisentraut <email@example.com> date : Sat, 18 Mar 2017 23:44:30 -0400 committer: Peter Eisentraut <firstname.lastname@example.org> date : Sat, 18 Mar 2017 23:44:30 -0400
Remove dead link.
commit : b04edf249c34daf9e9ca253a2a242e85bf6aea4b author : Robert Haas <email@example.com> date : Fri, 17 Mar 2017 09:32:34 -0400 committer: Robert Haas <firstname.lastname@example.org> date : Fri, 17 Mar 2017 09:32:34 -0400
David Christensen Discussion: http://postgr.es/m/82299377-1480-4439-9ABA-5828D71AA22E@endpoint.com
Fix and simplify check for whether we're running as Windows service.
commit : 9c52ddfcee067314a8db27ccd8c59dafe3059375 author : Heikki Linnakangas <email@example.com> date : Fri, 17 Mar 2017 11:14:01 +0200 committer: Heikki Linnakangas <firstname.lastname@example.org> date : Fri, 17 Mar 2017 11:14:01 +0200
If the process token contains SECURITY_SERVICE_RID, but it has been disabled by the SE_GROUP_USE_FOR_DENY_ONLY attribute, win32_is_service() would incorrectly report that we're running as a service. That situation arises, e.g. if postmaster is launched with a restricted security token, with the "Log in as Service" privilege explicitly removed. Replace the broken code with CheckProcessTokenMembership(), which does this correctly. Also replace similar code in win32_is_admin(), even though it got this right, for simplicity and consistency. Per bug #13755, reported by Breen Hagan. Back-patch to all supported versions. Patch by Takayuki Tsunakawa, reviewed by Michael Paquier. Discussion: https://www.postgresql.org/message-id/20151104062315.2745.67143%40wrigleys.postgresql.org
Avoid having vacuum set reltuples to 0 on non-empty relations in the presence of page pins, which leads to serious estimation errors in the planner. This particularly affects small heavily-accessed tables, especially where locking (e.g. from FK constraints) forces frequent vacuums for mxid cleanup.
commit : a494ff4b012b5ce89b2549d5dab6b66604083bf0 author : Andrew Gierth <email@example.com> date : Thu, 16 Mar 2017 22:33:38 +0000 committer: Andrew Gierth <firstname.lastname@example.org> date : Thu, 16 Mar 2017 22:33:38 +0000
Fix by keeping separate track of pages whose live tuples were actually counted vs. pages that were only scanned for freezing purposes. Thus, reltuples can only be set to 0 if all pages of the relation were actually counted. Backpatch to all supported versions. Per bug #14057 from Nicolas Baccelli, analyzed by me. Discussion: https://email@example.com
commit : 28fb0f10c9c38a4803b9fc09c5524efe9858a34a author : Peter Eisentraut <firstname.lastname@example.org> date : Tue, 14 Mar 2017 12:57:10 -0400 committer: Peter Eisentraut <email@example.com> date : Tue, 14 Mar 2017 12:57:10 -0400
From: Josh Soref <firstname.lastname@example.org>
Fix failure to mark init buffers as BM_PERMANENT.
commit : b2ae1d6c4da12be54260d39f866bcd9f31768037 author : Robert Haas <email@example.com> date : Tue, 14 Mar 2017 11:51:11 -0400 committer: Robert Haas <firstname.lastname@example.org> date : Tue, 14 Mar 2017 11:51:11 -0400
This could result in corruption of the init fork of an unlogged index if the ambuildempty routine for that index used shared buffers to create the init fork, which was true for brin, gin, gist, and hash indexes. Patch by me, based on an earlier patch by Michael Paquier, who also reviewed this one. This also incorporates an idea from Artur Zakirov. Discussion: http://postgr.es/m/CACYUyc8yccE4xfxhqxfh_Mh38j7dRFuxfaK1p6dSNAEUakxUyQ@mail.gmail.com
Remove unnecessary dependency on statement_timeout in prepared_xacts test.
commit : f6396dce0f15e31229d4d3c9285bdc5995b55ce1 author : Tom Lane <email@example.com> date : Mon, 13 Mar 2017 16:46:32 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 13 Mar 2017 16:46:32 -0400
Rather than waiting around for statement_timeout to expire, we can just try to take the table's lock in nowait mode. This saves some fraction under 4 seconds when running this test with prepared xacts available, and it guards against timeout-expired-anyway failures on very slow machines when prepared xacts are not available, as seen in a recent failure on axolotl for instance. This approach could fail if autovacuum were to take an exclusive lock on the test table concurrently, but there's no reason for it to do so. Since the main point here is to improve stability in the buildfarm, back-patch to all supported branches.
Ecpg should support COMMIT PREPARED and ROLLBACK PREPARED.
commit : d8c207437aa87f4f58305e96c408c74854ccfa65 author : Michael Meskes <email@example.com> date : Mon, 13 Mar 2017 20:44:13 +0100 committer: Michael Meskes <firstname.lastname@example.org> date : Mon, 13 Mar 2017 20:44:13 +0100
The problem was that "begin transaction" was issued automatically before executing COMMIT/ROLLBACK PREPARED if not in auto commit. This fix by Masahiko Sawada fixes this.
Fix pg_file_write() error handling.
commit : 0276da5eb31e9e6bf2d038ec5712b0b378904a70 author : Noah Misch <email@example.com> date : Sun, 12 Mar 2017 19:35:31 -0400 committer: Noah Misch <firstname.lastname@example.org> date : Sun, 12 Mar 2017 19:35:31 -0400
Detect fclose() failures; given "ln -s /dev/full $PGDATA/devfull", "pg_file_write('devfull', 'x', true)" now fails as it should. Don't leak a stream when fwrite() fails. Remove a born-ineffective test that aimed to skip zero-length writes. Back-patch to 9.2 (all supported versions).
Fix ancient connection leak in dblink
commit : c4613c3f496957ee5a203674bab66a5e53d06834 author : Joe Conway <email@example.com> date : Sat, 11 Mar 2017 13:33:30 -0800 committer: Joe Conway <firstname.lastname@example.org> date : Sat, 11 Mar 2017 13:33:30 -0800
When using unnamed connections with dblink, every time a new connection is made, the old one is leaked. Fix that. This has been an issue probably since dblink was first committed. Someone complained almost ten years ago, but apparently I decided not to pursue it at the time, and neither did anyone else, so it slipped between the cracks. Now that someone else has complained, fix in all supported branches. Discussion: (orig) https://postgr.es/m/flat/F680AB59-6D6F-4026-9599-1BE28880273D%40decibel.org#F680AB59-6D6F-4026-9599-1BE28880273D@decibel.org Discussion: (new) https://postgr.es/m/flat/0A3221C70F24FB45833433255569204D1F6ADF8C@G01JPEXMBYT05 Reported by: Jim Nasby and Takayuki Tsunakawa
Sanitize newlines in object names in "pg_restore -l" output.
commit : e6d2ba419577eadc59da688a5b21dba529c29e6c author : Tom Lane <email@example.com> date : Fri, 10 Mar 2017 14:15:09 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Fri, 10 Mar 2017 14:15:09 -0500
Commits 89e0bac86 et al replaced newlines with spaces in object names printed in SQL comments, but we neglected to consider that the same names are also printed by "pg_restore -l", and a newline would render the output unparseable by "pg_restore -L". Apply the same replacement in "-l" output. Since "pg_restore -L" doesn't actually examine any object names, only the dump ID field that starts each line, this is enough to fix things for its purposes. The previous fix was treated as a security issue, and we might have done that here as well, except that the issue was reported publicly to start with. Anyway it's hard to see how this could be exploited for SQL injection; "pg_restore -L" doesn't do much with the file except parse it for leading integers. Per bug #14587 from Milos Urbanek. Back-patch to all supported versions. Discussion: https://email@example.com
Fix a potential double-free in ecpg.
commit : 731afc91f0988604535db7838731cc1c355b160e author : Michael Meskes <firstname.lastname@example.org> date : Fri, 10 Mar 2017 10:32:41 +0100 committer: Michael Meskes <email@example.com> date : Fri, 10 Mar 2017 10:32:41 +0100
Fix timestamptz regression test to still work with latest IANA zone data.
commit : 52f6b2e5a640ab2e6a7a214cad7e95995e3c211d author : Tom Lane <firstname.lastname@example.org> date : Thu, 9 Mar 2017 17:20:11 -0500 committer: Tom Lane <email@example.com> date : Thu, 9 Mar 2017 17:20:11 -0500
The IANA timezone crew continues to chip away at their project of removing timezone abbreviations that have no real-world currency from their database. The tzdata2017a update removes all such abbreviations for South American zones, as well as much of the Pacific. This breaks some test cases in timestamptz.sql that were expecting America/Santiago and America/Caracas to have non-numeric abbreviations. The test cases involving America/Santiago seem to have selected that zone more or less at random, so just replace it with America/New_York, which is of similar longitude. The cases involving America/Caracas are harder since they were chosen to test a time-varying zone abbreviation around a point where it changed meaning in the backwards direction. Fortunately, Europe/Moscow has a similar case in 2014, and the MSK/MSD abbreviations are well enough attested that IANA seems unlikely to decide to remove them from the database in future. With these changes, this regression test should pass when using any IANA zone database from 2015 or later. One could wish that there were a few years more daylight on how out-of-date your zone database can be ... but really the --with-system-tzdata option is only meant for use on platforms where the zone database is kept up-to-date pretty faithfully, so I do not think this is a big objection. Discussion: https://firstname.lastname@example.org
Repair incorrect pg_dump labeling for some comments and security labels.
commit : 0ab75448eadec9712716276bb4a09d8e6a70f20c author : Tom Lane <email@example.com> date : Mon, 6 Mar 2017 19:33:59 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 6 Mar 2017 19:33:59 -0500
We attached no schema label to comments for procedural languages, casts, transforms, operator classes, operator families, or text search objects. The first three categories of objects don't really have schemas, but pg_dump treats them as if they do, and it seems like the TocEntry fields for their comments had better match the TocEntry fields for the parent objects. (As an example of a possible hazard, the type names in a CAST will be formatted with the assumption of a particular search_path, so failing to ensure that this same path is active for the COMMENT ON command could lead to an error or to attaching the comment to the wrong cast.) In the last six cases, this was a flat-out error --- possibly mine to begin with, but it was a long time ago. The security label for a procedural language was likewise not correctly labeled as to schema, and both the comment and security label for a procedural language were not correctly labeled as to owner. In simple cases the restore would accidentally work correctly anyway, since these comments and security labels would normally get emitted right after the owning object, and so the search path and active user would be correct anyhow. But it could fail in corner cases; for example a schema-selective restore would omit comments it should include. Giuseppe Broccolo noted the oversight, and proposed the correct fix, for text search dictionary objects; I found the rest by cross-checking other dumpComment() calls. These oversights are ancient, so back-patch all the way. Discussion: https://postgr.es/m/CAFzmHiWwwzLjzwM4x5ki5s_PDMR6NrkipZkjNnO3B0xEpBgJaA@mail.gmail.com
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
commit : e864cd25b4f5a85e0c236cf845daff99433937db author : Stephen Frost <email@example.com> date : Mon, 6 Mar 2017 17:04:55 -0500 committer: Stephen Frost <firstname.lastname@example.org> date : Mon, 6 Mar 2017 17:04:55 -0500
When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the information which can be associated with large objects. Currently, we also support COMMENTs and SECURITY LABELs with large objects and these were being silently dropped during a pg_upgrade as pg_dump would skip everything having to do with a large object and pg_upgrade only copied the tables mentioned to the new cluster. As the file copies happen after the catalog dump and reload, we can't simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode output but we also have to include the actual large object definition as well. With the definition, comments, and security labels in the pg_dump output and the file copies performed by pg_upgrade, all of the data and metadata associated with large objects is able to be successfully pulled forward across a pg_upgrade. In 9.6 and master, we can simply adjust the dump bitmask to indicate which components we don't want. In 9.5 and earlier, we have to put explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL or the data when in binary-upgrade mode. Adjustments made to the privileges regression test to allow another test (large_object.sql) to be added which explicitly leaves a large object with a comment in place to provide coverage of that case with pg_upgrade. Back-patch to all supported branches. Discussion: https://postgr.es/m/20170221162655.GE9812@tamriel.snowman.net
Add /config.cache to .gitignore in back branches
commit : 3703cfead94a18d9eff5b89203244d650a1a791c author : Bruce Momjian <email@example.com> date : Sat, 25 Feb 2017 13:04:22 -0500 committer: Bruce Momjian <firstname.lastname@example.org> date : Sat, 25 Feb 2017 13:04:22 -0500
For some reason config.cache was not being git-ignored in these back branches. Backpatch-through: 9.2 to 9.4
Fix sloppy handling of corner-case errors in fd.c.
commit : 775227590d40205a74042c01b5e6947ab47bccc7 author : Tom Lane <email@example.com> date : Tue, 21 Feb 2017 17:51:28 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Tue, 21 Feb 2017 17:51:28 -0500
Several places in fd.c had badly-thought-through handling of error returns from lseek() and close(). The fact that those would seldom fail on valid FDs is probably the reason we've not noticed this up to now; but if they did fail, we'd get quite confused. LruDelete and LruInsert actually just Assert'd that lseek never fails, which is pretty awful on its face. In LruDelete, we indeed can't throw an error, because that's likely to get called during error abort and so throwing an error would probably just lead to an infinite loop. But by the same token, throwing an error from the close() right after that was ill-advised, not to mention that it would've left the LRU state corrupted since we'd already unlinked the VFD from the list. I also noticed that really, most of the time, we should know the current seek position and it shouldn't be necessary to do an lseek here at all. As patched, if we don't have a seek position and an lseek attempt doesn't give us one, we'll close the file but then subsequent re-open attempts will fail (except in the somewhat-unlikely case that a FileSeek(SEEK_SET) call comes between and allows us to re-establish a known target seek position). This isn't great but it won't result in any state corruption. Meanwhile, having an Assert instead of an honest test in LruInsert is really dangerous: if that lseek failed, a subsequent read or write would read or write from the start of the file, not where the caller expected, leading to data corruption. In both LruDelete and FileClose, if close() fails, just LOG that and mark the VFD closed anyway. Possibly leaking an FD is preferable to getting into an infinite loop or corrupting the VFD list. Besides, as far as I can tell from the POSIX spec, it's unspecified whether or not the file has been closed, so treating it as still open could be the wrong thing anyhow. I also fixed a number of other places that were being sloppy about behaving correctly when the seekPos is unknown. Also, I changed FileSeek to return -1 with EINVAL for the cases where it detects a bad offset, rather than throwing a hard elog(ERROR). It seemed pretty inconsistent that some bad-offset cases would get a failure return while others got elog(ERROR). It was missing an offset validity check for the SEEK_CUR case on a closed file, too. Back-patch to all supported branches, since all this code is fundamentally identical in all of them. Discussion: https://email@example.com
doc: Update URL for plr
commit : b9f05be3855e8573d44e16af39682705cc33b9f5 author : Peter Eisentraut <firstname.lastname@example.org> date : Tue, 21 Feb 2017 12:35:57 -0500 committer: Peter Eisentraut <email@example.com> date : Tue, 21 Feb 2017 12:35:57 -0500
Fix documentation of to_char/to_timestamp TZ, tz, OF formatting patterns.
commit : df51e5285e43d196ba0f5caeddd06d1ce451e70c author : Tom Lane <firstname.lastname@example.org> date : Mon, 20 Feb 2017 10:05:01 -0500 committer: Tom Lane <email@example.com> date : Mon, 20 Feb 2017 10:05:01 -0500
These are only supported in to_char, not in the other direction, but the documentation failed to mention that. Also, describe TZ/tz as printing the time zone "abbreviation", not "name", because what they print is elsewhere referred to that way. Per bug #14558.
Make src/interfaces/libpq/test clean up after itself.
commit : 365db6b68e3562730048b63de98ef3505efdf9aa author : Tom Lane <firstname.lastname@example.org> date : Sun, 19 Feb 2017 17:18:10 -0500 committer: Tom Lane <email@example.com> date : Sun, 19 Feb 2017 17:18:10 -0500
It failed to remove a .o file during "make clean", and it lacked a .gitignore file entirely.
Adjust PL/Tcl regression test to dodge a possible bug or zone dependency.
commit : 5b5b2fb4035d3cd546be2406a3cfd816268b4d9b author : Tom Lane <firstname.lastname@example.org> date : Sun, 19 Feb 2017 16:14:53 -0500 committer: Tom Lane <email@example.com> date : Sun, 19 Feb 2017 16:14:53 -0500
One case in the PL/Tcl tests is observed to fail on RHEL5 with a Turkish time zone setting. It's not clear if this is an old Tcl bug or something odd about the zone data, but in any case that test is meant to see if the Tcl [clock] command works at all, not what its corner-case behaviors are. Therefore we have no need to test exactly which week a Sunday midnight is considered to fall into. Probe the following Tuesday instead. Discussion: https://firstname.lastname@example.org
Back-patch 9.4-era compiler warning fixes into older branches.
commit : edb02ed145d43fe2935bc478f4e5368f19b16a15 author : Tom Lane <email@example.com> date : Fri, 17 Feb 2017 17:12:14 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Fri, 17 Feb 2017 17:12:14 -0500
Back-patch commit 4e182361804f8688cef953c998e24134e606aea4 (another thing that longfin's version of clang doesn't like).
Back-patch 9.4-era compiler warning fixes into older branches.
commit : 4dcdc78ffe7c5e494f61285df2209ff1ad2aeedf author : Tom Lane <email@example.com> date : Fri, 17 Feb 2017 16:58:26 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Fri, 17 Feb 2017 16:58:26 -0500
This applies portions of commits b64b5ccb6 and b1aebbb6a to the older branches, in hopes of getting -Werror builds to succeed there. The applied changes simply remove useless tests, eg checking an unsigned variable to see if it is >= 0. Recent versions of clang warn about such tests by default.
Document usage of COPT environment variable for adjusting configure flags.
commit : 52c35254a1763fea836d1da0f327d870e1ec8228 author : Tom Lane <email@example.com> date : Fri, 17 Feb 2017 16:11:03 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Fri, 17 Feb 2017 16:11:03 -0500
Also add to the existing rather half-baked description of PROFILE, which does exactly the same thing, but I think people use it differently. Discussion: https://email@example.com
Make sure that hash join's bulk-tuple-transfer loops are interruptible.
commit : 030705e4fe27b4d3e9c9bfd38fda19e6d3be4248 author : Tom Lane <firstname.lastname@example.org> date : Wed, 15 Feb 2017 16:40:06 -0500 committer: Tom Lane <email@example.com> date : Wed, 15 Feb 2017 16:40:06 -0500
The loops in ExecHashJoinNewBatch(), ExecHashIncreaseNumBatches(), and ExecHashRemoveNextSkewBucket() are all capable of iterating over many tuples without ever doing a CHECK_FOR_INTERRUPTS, so that the backend might fail to respond to SIGINT or SIGTERM for an unreasonably long time. Fix that. In the case of ExecHashJoinNewBatch(), it seems useful to put the added CHECK_FOR_INTERRUPTS into ExecHashJoinGetSavedTuple() rather than directly in the loop, because that will also ensure that both principal code paths through ExecHashJoinOuterGetTuple() will do a CHECK_FOR_INTERRUPTS, which seems like a good idea to avoid surprises. Back-patch to all supported branches. Tom Lane and Thomas Munro Discussion: https://firstname.lastname@example.org
Ignore tablespace ACLs when ignoring schema ACLs.
commit : 27a8c8033a67853878335816b486a71477fd833d author : Noah Misch <email@example.com> date : Sun, 12 Feb 2017 16:03:41 -0500 committer: Noah Misch <firstname.lastname@example.org> date : Sun, 12 Feb 2017 16:03:41 -0500
The ALTER TABLE ALTER TYPE implementation can issue DROP INDEX and CREATE INDEX to refit existing indexes for the new column type. Since this CREATE INDEX is an implementation detail of an index alteration, the ensuing DefineIndex() should skip ACL checks specific to index creation. It already skips the namespace ACL check. Make it skip the tablespace ACL check, too. Back-patch to 9.2 (all supported versions). Reviewed by Tom Lane.