commit : ddb0843d44a53518cfbbb5c2fd535021d75d07cd author : Tom Lane <email@example.com> date : Mon, 9 May 2016 16:57:25 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 9 May 2016 16:57:25 -0400
commit : e712933c80a15719293f0c55eeb02e0aae401820 author : Peter Eisentraut <email@example.com> date : Mon, 9 May 2016 10:10:35 -0400 committer: Peter Eisentraut <firstname.lastname@example.org> date : Mon, 9 May 2016 10:10:35 -0400
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: c44f5f528f60ae8cbd849a0dda9ea3c4359f02aa
Release notes for 9.5.3, 9.4.8, 9.3.13, 9.2.17, 9.1.22.
commit : be13ee5ab0fe2ef0addce61089d052d0a1658e24 author : Tom Lane <email@example.com> date : Sat, 7 May 2016 17:26:24 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Sat, 7 May 2016 17:26:24 -0400
Distrust external OpenSSL clients; clear err queue
commit : 9b676fd49a34e1e4001f19331e9cb4a8d688bb06 author : Peter Eisentraut <email@example.com> date : Fri, 8 Apr 2016 13:48:14 -0400 committer: Peter Eisentraut <firstname.lastname@example.org> date : Fri, 8 Apr 2016 13:48:14 -0400
OpenSSL has an unfortunate tendency to mix per-session state error handling with per-thread error handling. This can cause problems when programs that link to libpq with OpenSSL enabled have some other use of OpenSSL; without care, one caller of OpenSSL may cause problems for the other caller. Backend code might similarly be affected, for example when a third party extension independently uses OpenSSL without taking the appropriate precautions. To fix, don't trust other users of OpenSSL to clear the per-thread error queue. Instead, clear the entire per-thread queue ahead of certain I/O operations when it appears that there might be trouble (these I/O operations mostly need to call SSL_get_error() to check for success, which relies on the queue being empty). This is slightly aggressive, but it's pretty clear that the other callers have a very dubious claim to ownership of the per-thread queue. Do this is both frontend and backend code. Finally, be more careful about clearing our own error queue, so as to not cause these problems ourself. It's possibly that control previously did not always reach SSLerrmessage(), where ERR_get_error() was supposed to be called to clear the queue's earliest code. Make sure ERR_get_error() is always called, so as to spare other users of OpenSSL the possibility of similar problems caused by libpq (as opposed to problems caused by a third party OpenSSL library like PHP's OpenSSL extension). Again, do this is both frontend and backend code. See bug #12799 and https://bugs.php.net/bug.php?id=68276 Based on patches by Dave Vitek and Peter Eisentraut. From: Peter Geoghegan <email@example.com>
Fix possible read past end of string in to_timestamp().
commit : 7bad282c34d967be71f52b8812834beb060a68da author : Tom Lane <firstname.lastname@example.org> date : Fri, 6 May 2016 12:09:20 -0400 committer: Tom Lane <email@example.com> date : Fri, 6 May 2016 12:09:20 -0400
to_timestamp() handles the TH/th format codes by advancing over two input characters, whatever those are. It failed to notice whether there were two characters available to be skipped, making it possible to advance the pointer past the end of the input string and keep on parsing. A similar risk existed in the handling of "Y,YYY" format: it would advance over three characters after the "," whether or not three characters were available. In principle this might be exploitable to disclose contents of server memory. But the security team concluded that it would be very hard to use that way, because the parsing loop would stop upon hitting any zero byte, and TH/th format codes can't be consecutive --- they have to follow some other format code, which would have to match whatever data is there. So it seems impractical to examine memory very much beyond the end of the input string via this bug; and the input string will always be in local memory not in disk buffers, making it unlikely that anything very interesting is close to it in a predictable way. So this doesn't quite rise to the level of needing a CVE. Thanks to Wolf Roediger for reporting this bug.
Update time zone data files to tzdata release 2016d.
commit : bfc39da640310b81d81cc7a03bc778d959624a1f author : Tom Lane <firstname.lastname@example.org> date : Thu, 5 May 2016 20:08:58 -0400 committer: Tom Lane <email@example.com> date : Thu, 5 May 2016 20:08:58 -0400
DST law changes in Russia (Magadan, Tomsk regions) and Venezuela. Historical corrections for Russia. There are new zone names Europe/Kirov and Asia/Tomsk reflecting the fact that these regions now have different time zone histories from adjacent regions.
doc: Fix more typos
commit : b94906f2d3222d56bf0935be565c2a94a84e858f author : Peter Eisentraut <firstname.lastname@example.org> date : Wed, 4 May 2016 14:07:00 -0400 committer: Peter Eisentraut <email@example.com> date : Wed, 4 May 2016 14:07:00 -0400
From: Alexander Law <firstname.lastname@example.org>
doc: Fix typos
commit : acf913480e2869949d9113444ff3073eab243855 author : Peter Eisentraut <email@example.com> date : Tue, 3 May 2016 21:06:25 -0400 committer: Peter Eisentraut <firstname.lastname@example.org> date : Tue, 3 May 2016 21:06:25 -0400
From: Alexander Law <email@example.com>
Fix configure's incorrect version tests for flex and perl.
commit : 6e3702e627b04b5a9c7fe2167b6d1fe1a57f0920 author : Tom Lane <firstname.lastname@example.org> date : Mon, 2 May 2016 11:18:11 -0400 committer: Tom Lane <email@example.com> date : Mon, 2 May 2016 11:18:11 -0400
awk's equality-comparison operator is "==" not "=". We got this right in many places, but not in configure's checks for supported version numbers of flex and perl. It hadn't been noticed because unsupported versions are so old as to be basically extinct in the wild, and because the only consequence is whether or not a WARNING flies by during configure. Daniel Gustafsson noted the problem with respect to the test for flex, I found the other by reviewing other awk calls.
Remove unused macros.
commit : c2c19afc82fb6a2fb97ed3479135a2e89e3c72e0 author : Heikki Linnakangas <firstname.lastname@example.org> date : Mon, 2 May 2016 10:07:49 +0300 committer: Heikki Linnakangas <email@example.com> date : Mon, 2 May 2016 10:07:49 +0300
CHECK_PAGE_OFFSET_RANGE() has been unused forever. CHECK_RELATION_BLOCK_RANGE() has been unused in pgstatindex.c ever since bt_page_stats() and bt_page_items() functions were moved from pgstattuple to pageinspect module. It still exists in pageinspect/btreefuncs.c. Daniel Gustafsson
Adjust DatumGetBool macro, this time for sure.
commit : a6c6789c46843988f8eef4afc462311f41bd6e27 author : Tom Lane <firstname.lastname@example.org> date : Thu, 28 Apr 2016 11:50:58 -0400 committer: Tom Lane <email@example.com> date : Thu, 28 Apr 2016 11:50:58 -0400
Commit 23a41573c attempted to fix the DatumGetBool macro to ignore bits in a Datum that are to the left of the actual bool value. But it did that by casting the Datum to bool; and on compilers that use C99 semantics for bool, that ends up being a whole-word test, not a 1-byte test. This seems to be the true explanation for contrib/seg failing in VS2015. To fix, use GET_1_BYTE() explicitly. I think in the previous patch, I'd had some idea of not having to commit to bool being exactly 1 byte wide, but regardless of what the compiler's bool is, boolean columns and Datums are certainly 1 byte wide. The previous fix was (eventually) back-patched into all active versions, so do likewise with this one.
Rename strtoi() to strtoint().
commit : cbff4b7085d779759e0e287ec3534d3da9ce72ab author : Tom Lane <firstname.lastname@example.org> date : Sat, 23 Apr 2016 16:53:15 -0400 committer: Tom Lane <email@example.com> date : Sat, 23 Apr 2016 16:53:15 -0400
NetBSD has seen fit to invent a libc function named strtoi(), which conflicts with the long-established static functions of the same name in datetime.c and ecpg's interval.c. While muttering darkly about intrusions on application namespace, we'll rename our functions to avoid the conflict. Back-patch to all supported branches, since this would affect attempts to build any of them on recent NetBSD. Thomas Munro
Fix planner failure with full join in RHS of left join.
commit : 6882dbd342d197e5f0bcc59059005780bc5c49a9 author : Tom Lane <firstname.lastname@example.org> date : Thu, 21 Apr 2016 20:05:58 -0400 committer: Tom Lane <email@example.com> date : Thu, 21 Apr 2016 20:05:58 -0400
Given a left join containing a full join in its righthand side, with the left join's joinclause referencing only one side of the full join (in a non-strict fashion, so that the full join doesn't get simplified), the planner could fail with "failed to build any N-way joins" or related errors. This happened because the full join was seen as overlapping the left join's RHS, and then recent changes within join_is_legal() caused that function to conclude that the full join couldn't validly be formed. Rather than try to rejigger join_is_legal() yet more to allow this, I think it's better to fix initsplan.c so that the required join order is explicit in the SpecialJoinInfo data structure. The previous coding there essentially ignored full joins, relying on the fact that we don't flatten them in the joinlist data structure to preserve their ordering. That's sufficient to prevent a wrong plan from being formed, but as this example shows, it's not sufficient to ensure that the right plan will be formed. We need to work a bit harder to ensure that the right plan looks sane according to the SpecialJoinInfos. Per bug #14105 from Vojtech Rylko. This was apparently induced by commit 8703059c6 (though now that I've seen it, I wonder whether there are related cases that could have failed before that); so back-patch to all active branches. Unfortunately, that patch also went into 9.0, so this bug is a regression that won't be fixed in that branch.
Improve TranslateSocketError() to handle more Windows error codes.
commit : 9028f404ef9605b585c176f7b0924069884cabfe author : Tom Lane <firstname.lastname@example.org> date : Thu, 21 Apr 2016 16:58:47 -0400 committer: Tom Lane <email@example.com> date : Thu, 21 Apr 2016 16:58:47 -0400
The coverage was rather lean for cases that bind() or listen() might return. Add entries for everything that there's a direct equivalent for in the set of Unix errnos that elog.c has heard of.
Remove dead code in win32.h.
commit : 5b13ad976a0143fbed15612db8962faa33e8d979 author : Tom Lane <firstname.lastname@example.org> date : Thu, 21 Apr 2016 16:16:19 -0400 committer: Tom Lane <email@example.com> date : Thu, 21 Apr 2016 16:16:19 -0400
There's no longer a need for the MSVC-version-specific code stanza that forcibly redefines errno code symbols, because since commit 73838b52 we're unconditionally redefining them in the stanza before this one anyway. Now it's merely confusing and ugly, so get rid of it; and improve the comment that explains what's going on here. Although this is just cosmetic, back-patch anyway since I'm intending to back-patch some less-cosmetic changes in this same hunk of code.
Provide errno-translation wrappers around bind() and listen() on Windows.
commit : b2bb59bd51849d4eec777171f6e402581e00d654 author : Tom Lane <firstname.lastname@example.org> date : Thu, 21 Apr 2016 15:44:18 -0400 committer: Tom Lane <email@example.com> date : Thu, 21 Apr 2016 15:44:18 -0400
Fix Windows builds to report something useful rather than "could not bind IPv4 socket: No error" when bind() fails. Back-patch of commits d1b7d4877b9a71f4 and 22989a8e34168f57. Discussion: <firstname.lastname@example.org>
Fix ruleutils.c's dumping of ScalarArrayOpExpr containing an EXPR_SUBLINK.
commit : 663624e60bd679ef7d4abeca1e68aceb5f2f5bbe author : Tom Lane <email@example.com> date : Thu, 21 Apr 2016 14:20:18 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Thu, 21 Apr 2016 14:20:18 -0400
When we shoehorned "x op ANY (array)" into the SQL syntax, we created a fundamental ambiguity as to the proper treatment of a sub-SELECT on the righthand side: perhaps what's meant is to compare x against each row of the sub-SELECT's result, or perhaps the sub-SELECT is meant as a scalar sub-SELECT that delivers a single array value whose members should be compared against x. The grammar resolves it as the former case whenever the RHS is a select_with_parens, making the latter case hard to reach --- but you can get at it, with tricks such as attaching a no-op cast to the sub-SELECT. Parse analysis would throw away the no-op cast, leaving a parsetree with an EXPR_SUBLINK SubLink directly under a ScalarArrayOpExpr. ruleutils.c was not clued in on this fine point, and would naively emit "x op ANY ((SELECT ...))", which would be parsed as the first alternative, typically leading to errors like "operator does not exist: text = text" during dump/reload of a view or rule containing such a construct. To fix, emit a no-op cast when dumping such a parsetree. This might well be exactly what the user wrote to get the construct accepted in the first place; and even if she got there with some other dodge, it is a valid representation of the parsetree. Per report from Karl Czajkowski. He mentioned only a case involving RLS policies, but actually the problem is very old, so back-patch to all supported branches. Report: <20160421001832.GB7976@moraine.isi.edu>
Honor PGCTLTIMEOUT environment variable for pg_regress' startup wait.
commit : 4c1c9f80b769120f2e809aa6447383c95c7705cf author : Tom Lane <email@example.com> date : Wed, 20 Apr 2016 23:48:13 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Wed, 20 Apr 2016 23:48:13 -0400
In commit 2ffa86962077c588 we made pg_ctl recognize an environment variable PGCTLTIMEOUT to set the default timeout for starting and stopping the postmaster. However, pg_regress uses pg_ctl only for the "stop" end of that; it has bespoke code for starting the postmaster, and that code has historically had a hard-wired 60-second timeout. Further buildfarm experience says it'd be a good idea if that timeout were also controlled by PGCTLTIMEOUT, so let's make it so. Like the previous patch, back-patch to all active branches. Discussion: <email@example.com>
doc: Add missing parentheses
commit : f719cd9bfbcf98ce9423b5c01184cf3bc627bbd7 author : Peter Eisentraut <firstname.lastname@example.org> date : Fri, 15 Apr 2016 20:44:10 -0400 committer: Peter Eisentraut <email@example.com> date : Fri, 15 Apr 2016 20:44:10 -0400
From: Alexander Law <firstname.lastname@example.org>
Remove trailing commas in enums.
commit : ccf893c4bdef19a778a621a4290c85716a257e72 author : Andres Freund <email@example.com> date : Thu, 14 Apr 2016 18:54:06 -0700 committer: Andres Freund <firstname.lastname@example.org> date : Thu, 14 Apr 2016 18:54:06 -0700
These aren't valid C89. Found thanks to gcc's -Wc90-c99-compat. These exist in differing places in most supported branches.
Fix pg_dump so pg_upgrade'ing an extension with simple opfamilies works.
commit : 3ef1f3a3ec1dee5a95a91124359f1bb58502afb4 author : Tom Lane <email@example.com> date : Wed, 13 Apr 2016 18:57:52 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Wed, 13 Apr 2016 18:57:52 -0400
As reported by Michael Feld, pg_upgrade'ing an installation having extensions with operator families that contain just a single operator class failed to reproduce the extension membership of those operator families. This caused no immediate ill effects, but would create problems when later trying to do a plain dump and restore, because the seemingly-not-part-of- the-extension operator families would appear separately in the pg_dump output, and then would conflict with the families created by loading the extension. This has been broken ever since extensions were introduced, and many of the standard contrib extensions are affected, so it's a bit astonishing nobody complained before. The cause of the problem is a perhaps-ill-considered decision to omit such operator families from pg_dump's output on the grounds that the CREATE OPERATOR CLASS commands could recreate them, and having explicit CREATE OPERATOR FAMILY commands would impede loading the dump script into pre-8.3 servers. Whatever the merits of that decision when 8.3 was being written, it looks like a poor tradeoff now. We can fix the pg_upgrade problem simply by removing that code, so that the operator families are dumped explicitly (and then will be properly made to be part of their extensions). Although this fixes the behavior of future pg_upgrade runs, it does nothing to clean up existing installations that may have improperly-linked operator families. Given the small number of complaints to date, maybe we don't need to worry about providing an automated solution for that; anyone who needs to clean it up can do so with manual "ALTER EXTENSION ADD OPERATOR FAMILY" commands, or even just ignore the duplicate-opfamily errors they get during a pg_restore. In any case we need this fix. Back-patch to all supported branches. Discussion: <email@example.com>
Fix possible use of uninitialised value in ts_headline()
commit : 94cda4f1065bcd21bdce664dc03eaa31faba0442 author : Teodor Sigaev <firstname.lastname@example.org> date : Fri, 8 Apr 2016 21:26:25 +0300 committer: Teodor Sigaev <email@example.com> date : Fri, 8 Apr 2016 21:26:25 +0300
Found during investigation of failure of skink buildfarm member and its valgrind report. Backpatch to all supported branches
Turn down MSVC compiler verbosity
commit : d2189a8026dbfa7542c96e4a63ef09b02e625748 author : Andrew Dunstan <firstname.lastname@example.org> date : Fri, 8 Apr 2016 12:25:10 -0400 committer: Andrew Dunstan <email@example.com> date : Fri, 8 Apr 2016 12:25:10 -0400
Most of what is produced by the detailed verbosity level is of no interest at all, so switch to the normal level for more usable output. Christian Ullrich Backpatch to all live branches
Fix latent portability issue in pgwin32_dispatch_queued_signals().
commit : b1b6aa88b146e0e7ca9b2eb5911d1f56064ccabb author : Tom Lane <firstname.lastname@example.org> date : Mon, 4 Apr 2016 11:13:17 -0400 committer: Tom Lane <email@example.com> date : Mon, 4 Apr 2016 11:13:17 -0400
The first iteration of the signal-checking loop would compute sigmask(0) which expands to 1<<(-1) which is undefined behavior according to the C standard. The lack of field reports of trouble suggest that it evaluates to 0 on all existing Windows compilers, but that's hardly something to rely on. Since signal 0 isn't a queueable signal anyway, we can just make the loop iterate from 1 instead, and save a few cycles as well as avoiding the undefined behavior. In passing, avoid evaluating the volatile expression UNBLOCKED_SIGNAL_QUEUE twice in a row; there's no reason to waste cycles like that. Noted by Aleksander Alekseev, though this isn't his proposed fix. Back-patch to all supported branches.
Avoid possibly-unsafe use of Windows' FormatMessage() function.
commit : 6cd30292bfc38edcae0c1d9c127265cfe665a569 author : Tom Lane <firstname.lastname@example.org> date : Tue, 29 Mar 2016 11:54:58 -0400 committer: Tom Lane <email@example.com> date : Tue, 29 Mar 2016 11:54:58 -0400
Whenever this function is used with the FORMAT_MESSAGE_FROM_SYSTEM flag, it's good practice to include FORMAT_MESSAGE_IGNORE_INSERTS as well. Otherwise, if the message contains any %n insertion markers, the function will try to fetch argument strings to substitute --- which we are not passing, possibly leading to a crash. This is exactly analogous to the rule about not giving printf() a format string you're not in control of. Noted and patched by Christian Ullrich. Back-patch to all supported branches.