Skip to main content

Browse the archive

https://github.com/postgres/postgres
07 April 2024, 13:56:23 UTC
sort by:
Revision Author Date Message Commit Date
cd5a652 Tom Lane 09 May 2016, 20:53:56 UTC Stamp 9.3.13. 09 May 2016, 20:53:56 UTC
b81b977 Peter Eisentraut 09 May 2016, 14:08:57 UTC Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: e5be28ef3e1f11df901bb62f6228f32f156307e3 09 May 2016, 14:08:57 UTC
3f13193 Tom Lane 07 May 2016, 21:26:24 UTC Release notes for 9.5.3, 9.4.8, 9.3.13, 9.2.17, 9.1.22. 07 May 2016, 21:26:24 UTC
a9d8644 Peter Eisentraut 08 April 2016, 17:48:14 UTC Distrust external OpenSSL clients; clear err queue 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 <pg@bowt.ie> 07 May 2016, 04:10:17 UTC
e1d88f9 Tom Lane 07 May 2016, 02:05:51 UTC Fix pg_upgrade to not fail when new-cluster TOAST rules differ from old. This patch essentially reverts commit 4c6780fd17aa43ed, in favor of a much simpler solution for the case where the new cluster would choose to create a TOAST table but the old cluster doesn't have one: just don't create a TOAST table. The existing code failed in at least two different ways if the situation arose: (1) ALTER TABLE RESET didn't grab an exclusive lock, so that the lock sanity check in create_toast_table failed; (2) pg_upgrade did not provide a pg_type OID for the new toast table, so that the crosscheck in TypeCreate failed. While both these problems were introduced by later patches, they show that the hack being used to cause TOAST table creation is overwhelmingly fragile (and untested). I also note that before the TypeCreate crosscheck was added, the code would have resulted in assigning an indeterminate pg_type OID to the toast table, possibly causing a later OID conflict in that catalog; so that it didn't really work even when committed. If we simply don't create a TOAST table, there will only be a problem if the code tries to store a tuple that's wider than a page, and field compression isn't sufficient to get it under a page. Given that the TOAST creation threshold is intended to be about a quarter of a page, it's very hard to believe that cross-version differences in the do-we-need-a-toast- table heuristic could result in an observable problem. So let's just follow the old version's conclusion about whether a TOAST table is needed. (If we ever do change needs_toast_table() so much that this conclusion doesn't apply, we can devise a solution at that time, and hopefully do it in a less klugy way than 4c6780fd17aa43ed did.) Back-patch to 9.3, like the previous patch. Discussion: <8110.1462291671@sss.pgh.pa.us> 07 May 2016, 02:05:51 UTC
462456d Tom Lane 06 May 2016, 16:09:20 UTC Fix possible read past end of string in to_timestamp(). 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. 06 May 2016, 16:09:20 UTC
d30c67a Tom Lane 06 May 2016, 00:08:58 UTC Update time zone data files to tzdata release 2016d. 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. 06 May 2016, 00:09:22 UTC
7432409 Peter Eisentraut 04 May 2016, 18:07:00 UTC doc: Fix more typos From: Alexander Law <exclusion@gmail.com> 04 May 2016, 18:07:24 UTC
e0e023b Peter Eisentraut 04 May 2016, 01:06:25 UTC doc: Fix typos From: Alexander Law <exclusion@gmail.com> 04 May 2016, 01:07:48 UTC
6c2e2b3 Tom Lane 02 May 2016, 15:18:11 UTC Fix configure's incorrect version tests for flex and perl. 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. 02 May 2016, 15:18:11 UTC
586d75a Heikki Linnakangas 02 May 2016, 07:07:49 UTC Remove unused macros. 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 02 May 2016, 07:09:03 UTC
67349e5 Tom Lane 30 April 2016, 00:19:38 UTC Fix mishandling of equivalence-class tests in parameterized plans. Given a three-or-more-way equivalence class, such as X.Y = Y.Y = Z.Z, it was possible for the planner to omit one of the quals needed to enforce that all members of the equivalence class are actually equal. This only happened in the case of a parameterized join node for two of the relations, that is a plan tree like Nested Loop -> Scan X -> Nested Loop -> Scan Y -> Scan Z Filter: Z.Z = X.X The eclass machinery normally expects to apply X.X = Y.Y when those two relations are joined, but in this shape of plan tree they aren't joined until the top node --- and, if the lower nested loop is marked as parameterized by X, the top node will assume that the relevant eclass condition(s) got pushed down into the lower node. On the other hand, the scan of Z assumes that it's only responsible for constraining Z.Z to match any one of the other eclass members. So one or another of the required quals sometimes fell between the cracks, depending on whether consideration of the eclass in get_joinrel_parampathinfo() for the lower nested loop chanced to generate X.X = Y.Y or X.X = Z.Z as the appropriate constraint there. If it generated the latter, it'd erroneously suppose that the Z scan would take care of matters. To fix, force X.X = Y.Y to be generated and applied at that join node when this case occurs. This is *extremely* hard to hit in practice, because various planner behaviors conspire to mask the problem; starting with the fact that the planner doesn't really like to generate a parameterized plan of the above shape. (It might have been impossible to hit it before we tweaked things to allow this plan shape for star-schema cases.) Many thanks to Alexander Kirkouski for submitting a reproducible test case. The bug can be demonstrated in all branches back to 9.2 where parameterized paths were introduced, so back-patch that far. 30 April 2016, 00:19:38 UTC
707c44f Tom Lane 28 April 2016, 15:50:58 UTC Adjust DatumGetBool macro, this time for sure. 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. 28 April 2016, 15:51:17 UTC
4f29edb Bruce Momjian 28 April 2016, 12:29:02 UTC pg_upgrade: Fix indentation of if() block Incorrect indentation introduced in commit 3d2e1851096752c3ca4dee5c16b552332de09946. Reported-by: Andres Freund Backpatch-through: 9.3 and 9.4 only 28 April 2016, 12:29:02 UTC
252c358 Tom Lane 23 April 2016, 20:53:15 UTC Rename strtoi() to strtoint(). 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 23 April 2016, 20:53:15 UTC
23da66f Peter Eisentraut 23 April 2016, 18:48:02 UTC doc: Fix typos From: Erik Rijkers <er@xs4all.nl> 23 April 2016, 18:53:47 UTC
ab5c6d0 Magnus Hagander 22 April 2016, 09:18:59 UTC Add putenv support for msvcrt from Visual Studio 2013 This was missed when VS 2013 support was added. Michael Paquier 22 April 2016, 09:20:18 UTC
d9742ac Tom Lane 22 April 2016, 00:05:58 UTC Fix planner failure with full join in RHS of left join. 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. 22 April 2016, 00:05:58 UTC
82bf369 Tom Lane 21 April 2016, 20:58:47 UTC Improve TranslateSocketError() to handle more Windows error codes. 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. 21 April 2016, 20:59:08 UTC
8735150 Tom Lane 21 April 2016, 20:16:19 UTC Remove dead code in win32.h. 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. 21 April 2016, 20:16:19 UTC
8f95184 Tom Lane 21 April 2016, 19:44:18 UTC Provide errno-translation wrappers around bind() and listen() on Windows. 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: <4065.1452450340@sss.pgh.pa.us> 21 April 2016, 19:44:18 UTC
e5882f2 Tom Lane 21 April 2016, 18:20:18 UTC Fix ruleutils.c's dumping of ScalarArrayOpExpr containing an EXPR_SUBLINK. 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> 21 April 2016, 18:20:18 UTC
691073b Tom Lane 21 April 2016, 03:48:13 UTC Honor PGCTLTIMEOUT environment variable for pg_regress' startup wait. 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: <13969.1461191936@sss.pgh.pa.us> 21 April 2016, 03:48:13 UTC
6ec1ff8 Tom Lane 18 April 2016, 17:33:07 UTC Further reduce the number of semaphores used under --disable-spinlocks. Per discussion, there doesn't seem to be much value in having NUM_SPINLOCK_SEMAPHORES set to 1024: under any scenario where you are running more than a few backends concurrently, you really had better have a real spinlock implementation if you want tolerable performance. And 1024 semaphores is a sizable fraction of the system-wide SysV semaphore limit on many platforms. Therefore, reduce this setting's default value to 128 to make it less likely to cause out-of-semaphores problems. 18 April 2016, 17:33:07 UTC
35166fd Tom Lane 18 April 2016, 17:19:52 UTC Fix --disable-spinlocks in 9.2 and 9.3 branches. My back-patch of the 9.4-era commit 44cd47c1d49655c5 into 9.2 and 9.3 fixed HPPA builds as expected, but it broke --disable-spinlocks builds, because the dummy spinlock is initialized before the underlying semaphore infrastructure is alive. In 9.4 and up this works because of commit daa7527afc227443, which decoupled initialization of an slock_t variable from access to the actual system semaphore object. The best solution seems to be to back-port that patch, which should be a net win anyway because it improves the usability of --disable-spinlocks builds in the older branches; and it's been out long enough now to not be worrisome from a stability perspective. 18 April 2016, 17:19:52 UTC
0a32768 Tom Lane 16 April 2016, 18:50:54 UTC Fix missing "static". Per buildfarm member pademelon. 16 April 2016, 18:50:54 UTC
992df96 Tom Lane 16 April 2016, 14:42:07 UTC Make fallback implementation of pg_memory_barrier() work in 9.2 and 9.3. Back-patch 9.4-era commit 44cd47c1d49655c5 into 9.2 and 9.3. As with my back-patches of yesterday, this was not seen as necessary at the time because we didn't expect barrier.h to need to work before 9.4, but commit 37de8de9e33606a0 invalidated that theory. Per an attempt to run gaur and pademelon over old branches they've not been run on since ~2013. 16 April 2016, 14:42:07 UTC
9b2dc08 Peter Eisentraut 16 April 2016, 00:44:10 UTC doc: Add missing parentheses From: Alexander Law <exclusion@gmail.com> 16 April 2016, 00:54:23 UTC
f4f4f69 Tom Lane 15 April 2016, 20:49:48 UTC Sync 9.2 and 9.3 versions of barrier.h with 9.4's version. We weren't particularly maintaining barrier.h before 9.4, because nothing was using it in those branches. Well, nothing until commit 37de8de9e got back-patched. That broke 9.2 and 9.3 for some non-mainstream platforms that we haven't been testing in the buildfarm, including icc on ia64, HPPA, and Alpha. This commit effectively back-patches commits e5592c61a, 89779bf2c, and 747ca6697, though I did it just by copying the file (less copyright date updates) rather than by cherry-picking those commits. Per an attempt to run gaur and pademelon over old branches they've not been run on since ~2013. 15 April 2016, 20:49:48 UTC
6e53bb4 Andres Freund 15 April 2016, 02:22:50 UTC Fix non-C89-compliant initialization of array in parallel.c. In newer branches this was already fixed in 59202fae04. Found using clang's -Wc99-extensions. 15 April 2016, 02:27:49 UTC
f1d26d3 Andres Freund 15 April 2016, 01:54:06 UTC Remove trailing commas in enums. These aren't valid C89. Found thanks to gcc's -Wc90-c99-compat. These exist in differing places in most supported branches. 15 April 2016, 02:25:17 UTC
34bf6bc Tom Lane 13 April 2016, 22:57:52 UTC Fix pg_dump so pg_upgrade'ing an extension with simple opfamilies works. 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: <20228.1460575691@sss.pgh.pa.us> 13 April 2016, 22:57:52 UTC
f6b8116 Tom Lane 11 April 2016, 22:17:02 UTC Fix freshly-introduced PL/Python portability bug. It turns out that those PyErr_Clear() calls I removed from plpy_elog.c in 7e3bb080387f4143 et al were not quite as random as they appeared: they mask a Python 2.3.x bug. (Specifically, it turns out that PyType_Ready() can fail if the error indicator is set on entry, and PLy_traceback's fetch of frame.f_code may be the first operation in a session that requires the "frame" type to be readied. Ick.) Put back the clear call, but in a more centralized place closer to what it's protecting, and this time with a comment warning what it's really for. Per buildfarm member prairiedog. Although prairiedog was only failing on HEAD, it seems clearly possible for this to occur in older branches as well, so back-patch to 9.2 the same as the previous patch. 11 April 2016, 22:17:02 UTC
8d82e6e Tom Lane 11 April 2016, 03:15:55 UTC Fix access-to-already-freed-memory issue in plpython's error handling. PLy_elog() could attempt to access strings that Python had already freed, because the strings that PLy_get_spi_error_data() returns are simply pointers into storage associated with the error "val" PyObject. That's fine at the instant PLy_get_spi_error_data() returns them, but just after that PLy_traceback() intentionally releases the only refcount on that object, allowing it to be freed --- so that the strings we pass to ereport() are dangling pointers. In principle this could result in garbage output or a coredump. In practice, I think the risk is pretty low, because there are no Python operations between where we decrement that refcount and where we use the strings (and copy them into PG storage), and thus no reason for Python to recycle the storage. Still, it's clearly hazardous, and it leads to Valgrind complaints when running under a Valgrind that hasn't been lobotomized to ignore Python memory allocations. The code was a mess anyway: we fetched the error data out of Python (clearing Python's error indicator) with PyErr_Fetch, examined it, pushed it back into Python with PyErr_Restore (re-setting the error indicator), then immediately pulled it back out with another PyErr_Fetch. Just to confuse matters even more, there were some gratuitous-and-yet-hazardous PyErr_Clear calls in the "examine" step, and we didn't get around to doing PyErr_NormalizeException until after the second PyErr_Fetch, making it even less clear which object was being manipulated where and whether we still had a refcount on it. (If PyErr_NormalizeException did substitute a different "val" object, it's possible that the problem could manifest for real, because then we'd be doing assorted Python stuff with no refcount on the object we have string pointers into.) So, rearrange all that into some semblance of sanity, and don't decrement the refcount on the Python error objects until the end of PLy_elog(). In HEAD, I failed to resist the temptation to reformat some messy bits from 5c3c3cd0a3046339 along the way. Back-patch as far as 9.2, because the code is substantially the same that far back. I believe that 9.1 has the bug as well; but the code around it is rather different and I don't want to take a chance on breaking something for what seems a low-probability problem. 11 April 2016, 03:15:55 UTC
9d3fb20 Teodor Sigaev 08 April 2016, 18:25:59 UTC Fix possible use of uninitialised value in ts_headline() Found during investigation of failure of skink buildfarm member and its valgrind report. Backpatch to all supported branches 08 April 2016, 18:25:59 UTC
ca5d6ed Andrew Dunstan 08 April 2016, 16:25:10 UTC Turn down MSVC compiler verbosity 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 08 April 2016, 16:29:34 UTC
fa4eab8 Alvaro Herrera 05 April 2016, 22:03:42 UTC Fix broken ALTER INDEX documentation Commit b8a91d9d1c put the description of the new IF EXISTS clause in the wrong place -- move it where it belongs. Backpatch to 9.2. 05 April 2016, 22:03:42 UTC
43b73d1 Tom Lane 04 April 2016, 15:13:17 UTC Fix latent portability issue in pgwin32_dispatch_queued_signals(). 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. 04 April 2016, 15:13:35 UTC
cbf4f6b Tom Lane 30 March 2016, 01:38:15 UTC Remove TZ environment-variable entry from postgres reference page. The server hasn't paid attention to the TZ environment variable since commit ca4af308c32d03db, but that commit missed removing this documentation reference, as did commit d883b916a947a3c6 which added the reference where it now belongs (initdb). Back-patch to 9.2 where the behavior changed. Also back-patch d883b916a947a3c6 as needed. Matthew Somerville 30 March 2016, 01:38:15 UTC
11cc7bb Tom Lane 29 March 2016, 15:54:57 UTC Avoid possibly-unsafe use of Windows' FormatMessage() function. 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. 29 March 2016, 15:54:57 UTC
a3c6439 Tom Lane 28 March 2016, 20:12:29 UTC Stamp 9.3.12. 28 March 2016, 20:12:29 UTC
e0f4c9e Peter Eisentraut 28 March 2016, 06:50:07 UTC Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 4891e88b1972d0091e8e5cefd145600801ba58be 28 March 2016, 06:50:07 UTC
9d05096 Tom Lane 27 March 2016, 23:26:26 UTC Release notes for 9.5.2, 9.4.7, 9.3.12, 9.2.16, 9.1.21. 27 March 2016, 23:26:26 UTC
65a8a3f Andres Freund 27 March 2016, 15:47:50 UTC Change various Gin*Is* macros to return 0/1. Returning the direct result of bit arithmetic, in a macro intended to be used in a boolean manner, can be problematic if the return value is stored in a variable of type 'bool'. If bool is implemented using C99's _Bool, that can lead to comparison failures if the variable is then compared again with the expression (see ginStepRight() for an example that fails), as _Bool forces the result to be 0/1. That happens in some configurations of newer MSVC compilers. It's also problematic when storing the result of such an expression in a narrower type. Several gin macros have been declared in that style since gin's initial commit in 8a3631f8d86. There's a lot more macros like this, but this is the only one causing regression test failures; and I don't want to commit and backpatch a larger patch with lots of conflicts just before the next set of minor releases. Discussion: 20150811154237.GD17575@awork2.anarazel.de Backpatch: All supported branches 27 March 2016, 15:47:50 UTC
8ea71fd Tom Lane 26 March 2016, 19:58:44 UTC Modernize zic's test for valid timezone abbreviations. We really need to sync all of our IANA-derived timezone code with upstream, but that's going to be a large patch and I certainly don't care to shove such a thing into stable branches immediately before a release. As a stopgap, copy just the tzcode2016c logic that checks validity of timezone abbreviations. This prevents getting multiple "time zone abbreviation differs from POSIX standard" bleats with tzdata 2014b and later. 26 March 2016, 19:59:26 UTC
8e16592 Tom Lane 25 March 2016, 23:03:08 UTC Update time zone data files to tzdata release 2016c. DST law changes in Azerbaijan, Chile, Haiti, Palestine, and Russia (Altai, Astrakhan, Kirov, Sakhalin, Ulyanovsk regions). Historical corrections for Lithuania, Moldova, Russia (Kaliningrad, Samara, Volgograd). As of 2015b, the keepers of the IANA timezone database started to use numeric time zone abbreviations (e.g., "+04") instead of inventing abbreviations not found in the wild like "ASTT". This causes our rather old copy of zic to whine "warning: time zone abbreviation differs from POSIX standard" several times during "make install". This warning is harmless according to the IANA folk, and I don't see any problems with these abbreviations in some simple tests; but it seems like now would be a good time to update our copy of the tzcode stuff. I'll look into that soon. 25 March 2016, 23:03:39 UTC
a0adf38 Andrew Dunstan 19 March 2016, 22:36:35 UTC Remove dependency on psed for MSVC builds. Modern Perl has removed psed from its core distribution, so it might not be readily available on some build platforms. We therefore replace its use with a Perl script generated by s2p, which is equivalent to the sed script. The latter is retained for non-MSVC builds to avoid creating a new hard dependency on Perl for non-Windows tarball builds. Backpatch to all live branches. Michael Paquier and me. 19 March 2016, 22:51:01 UTC
c02aae4 Tom Lane 17 March 2016, 03:18:07 UTC Fix "pg_bench -C -M prepared". This didn't work because when we dropped and re-established a database connection, we did not bother to reset session-specific state such as the statements-are-prepared flags. The st->prepared[] array certainly needs to be flushed, and I cleared a couple of other fields as well that couldn't possibly retain meaningful state for a new connection. In passing, fix some bogus comments and strange field order choices. Per report from Robins Tharakan. 17 March 2016, 03:18:07 UTC
cfc5357 Alvaro Herrera 15 March 2016, 20:57:16 UTC Fix typos in comments 15 March 2016, 20:57:16 UTC
4b505c2 Tom Lane 15 March 2016, 17:19:58 UTC Cope if platform declares mbstowcs_l(), but not locale_t, in <xlocale.h>. Previously, we included <xlocale.h> only if necessary to get the definition of type locale_t. According to notes in PGAC_TYPE_LOCALE_T, this is important because on some versions of glibc that file supplies an incompatible declaration of locale_t. (This info may be obsolete, because on my RHEL6 box that seems to be the *only* definition of locale_t; but there may still be glibc's in the wild for which it's a live concern.) It turns out though that on FreeBSD and maybe other BSDen, you can get locale_t from stdlib.h or locale.h but mbstowcs_l() and friends only from <xlocale.h>. This was leaving us compiling calls to mbstowcs_l() and friends with no visible prototype, which causes a warning and could possibly cause actual trouble, since it's not declared to return int. Hence, adjust the configure checks so that we'll include <xlocale.h> either if it's necessary to get type locale_t or if it's necessary to get a declaration of mbstowcs_l(). Report and patch by Aleksander Alekseev, somewhat whacked around by me. Back-patch to all supported branches, since we have been using mbstowcs_l() since 9.1. 15 March 2016, 17:19:58 UTC
0576de5 Tom Lane 14 March 2016, 15:31:22 UTC Add missing NULL terminator to list_SECURITY_LABEL_preposition[]. On the machines I tried this on, pressing TAB after SECURITY LABEL led to being offered ON and FOR as intended, plus random other keywords (varying across machines). But if you were a bit more unlucky you'd get a crash, as reported by nummervet@mail.ru in bug #14019. Seems to have been an aboriginal error in the SECURITY LABEL patch, commit 4d355a8336e0f226. Hence, back-patch to all supported versions. There's no bug in HEAD, though, thanks to our recent tab-completion rewrite. 14 March 2016, 15:31:39 UTC
270d8a1 Magnus Hagander 10 March 2016, 12:48:58 UTC Avoid crash on old Windows with AVX2-capable CPU for VS2013 builds The Visual Studio 2013 CRT generates invalid code when it makes a 64-bit build that is later used on a CPU that supports AVX2 instructions using a version of Windows before 7SP1/2008R2SP1. Detect this combination, and in those cases turn off the generation of FMA3, per recommendation from the Visual Studio team. The bug is actually in the CRT shipping with Visual Studio 2013, but Microsoft have stated they're only fixing it in newer major versions. The fix is therefor conditioned specifically on being built with this version of Visual Studio, and not previous or later versions. Author: Christian Ullrich 10 March 2016, 13:10:48 UTC
bfa282a Andres Freund 10 March 2016, 02:53:54 UTC Avoid unlikely data-loss scenarios due to rename() without fsync. Renaming a file using rename(2) is not guaranteed to be durable in face of crashes. Use the previously added durable_rename()/durable_link_or_rename() in various places where we previously just renamed files. Most of the changed call sites are arguably not critical, but it seems better to err on the side of too much durability. The most prominent known case where the previously missing fsyncs could cause data loss is crashes at the end of a checkpoint. After the actual checkpoint has been performed, old WAL files are recycled. When they're filled, their contents are fdatasynced, but we did not fsync the containing directory. An OS/hardware crash in an unfortunate moment could then end up leaving that file with its old name, but new content; WAL replay would thus not replay it. Reported-By: Tomas Vondra Author: Michael Paquier, Tomas Vondra, Andres Freund Discussion: 56583BDD.9060302@2ndquadrant.com Backpatch: All supported branches 10 March 2016, 02:53:54 UTC
e069848 Andres Freund 10 March 2016, 02:53:54 UTC Introduce durable_rename() and durable_link_or_rename(). Renaming a file using rename(2) is not guaranteed to be durable in face of crashes; especially on filesystems like xfs and ext4 when mounted with data=writeback. To be certain that a rename() atomically replaces the previous file contents in the face of crashes and different filesystems, one has to fsync the old filename, rename the file, fsync the new filename, fsync the containing directory. This sequence is not generally adhered to currently; which exposes us to data loss risks. To avoid having to repeat this arduous sequence, introduce durable_rename(), which wraps all that. Also add durable_link_or_rename(). Several places use link() (with a fallback to rename()) to rename a file, trying to avoid replacing the target file out of paranoia. Some of those rename sequences need to be durable as well. There seems little reason extend several copies of the same logic, so centralize the link() callers. This commit does not yet make use of the new functions; they're used in a followup commit. Author: Michael Paquier, Andres Freund Discussion: 56583BDD.9060302@2ndquadrant.com Backpatch: All supported branches 10 March 2016, 02:53:54 UTC
1ab7a16 Tom Lane 09 March 2016, 19:51:01 UTC Fix incorrect handling of NULL index entries in indexed ROW() comparisons. An index search using a row comparison such as ROW(a, b) > ROW('x', 'y') would stop upon reaching a NULL entry in the "b" column, ignoring the fact that there might be non-NULL "b" values associated with later values of "a". This happens because _bt_mark_scankey_required() marks the subsidiary scankey for "b" as required, which is just wrong: it's for a column after the one with the first inequality key (namely "a"), and thus can't be considered a required match. This bit of brain fade dates back to the very beginnings of our support for indexed ROW() comparisons, in 2006. Kind of astonishing that no one came across it before Glen Takahashi, in bug #14010. Back-patch to all supported versions. Note: the given test case doesn't actually fail in unpatched 9.1, evidently because the fix for bug #6278 (i.e., stopping at nulls in either scan direction) is required to make it fail. I'm sure I could devise a case that fails in 9.1 as well, perhaps with something involving making a cursor back up; but it doesn't seem worth the trouble. 09 March 2016, 19:51:01 UTC
12449f1 Andres Freund 08 March 2016, 22:59:29 UTC ltree: Zero padding bytes when allocating memory for externally visible data. ltree/ltree_gist/ltxtquery's headers stores data at MAXALIGN alignment, requiring some padding bytes. So far we left these uninitialized. Zero those by using palloc0. Author: Andres Freund Reported-By: Andres Freund / valgrind / buildarm animal skink Backpatch: 9.1- 08 March 2016, 22:59:29 UTC
44f9f1f Andres Freund 08 March 2016, 21:33:24 UTC plperl: Correctly handle empty arrays in plperl_ref_from_pg_array. plperl_ref_from_pg_array() didn't consider the case that postgrs arrays can have 0 dimensions (when they're empty) and accessed the first dimension without a check. Fix that by special casing the empty array case. Author: Alex Hunsaker Reported-By: Andres Freund / valgrind / buildfarm animal skink Discussion: 20160308063240.usnzg6bsbjrne667@alap3.anarazel.de Backpatch: 9.1- 08 March 2016, 21:42:58 UTC
b73e816 Tom Lane 07 March 2016, 15:40:44 UTC Fix backwards test for Windows service-ness in pg_ctl. A thinko in a96761391 caused pg_ctl to get it exactly backwards when deciding whether to report problems to the Windows eventlog or to stderr. Per bug #14001 from Manuel Mathar, who also identified the fix. Like the previous patch, back-patch to all supported branches. 07 March 2016, 15:41:01 UTC
a35f85a Tom Lane 07 March 2016, 00:21:03 UTC Fix not-terribly-safe coding in NIImportOOAffixes() and NIImportAffixes(). There were two places in spell.c that supposed that they could search for a location in a string produced by lowerstr() and then transpose the offset into the original string. But this fails completely if lowerstr() transforms any characters into characters of different byte length, as can happen in Turkish UTF8 for instance. We'd added some comments about this coding in commit 51e78ab4ff328296, but failed to realize that it was not merely confusing but wrong. Coverity complained about this code years ago, but in such an opaque fashion that nobody understood what it was on about. I'm not entirely sure that this issue *is* what it's on about, actually, but perhaps this patch will shut it up -- and in any case the problem is clear. Back-patch to all supported branches. 07 March 2016, 00:21:03 UTC
fbee403 Robert Haas 04 March 2016, 17:11:30 UTC Fix compile breakage due to 0315dfa8f4afa8390383119330ca0bf241be4ad4. I wasn't careful enough when back-patching. 04 March 2016, 17:15:36 UTC
54139ac Robert Haas 04 March 2016, 16:53:20 UTC Fix query-based tab completion for multibyte characters. The existing code confuses the byte length of the string (which is relevant when passing it to pg_strncasecmp) with the character length of the string (which is relevant when it is used with the SQL substring function). Separate those two concepts. Report and patch by Kyotaro Horiguchi, reviewed by Thomas Munro and reviewed and further revised by me. 04 March 2016, 16:57:31 UTC
ff45274 Tom Lane 01 March 2016, 00:11:38 UTC Improve error message for rejecting RETURNING clauses with dropped columns. This error message was written with only ON SELECT rules in mind, but since then we also made RETURNING-clause targetlists go through the same logic. This means that you got a rather off-topic error message if you tried to add a rule with RETURNING to a table having dropped columns. Ideally we'd just support that, but some preliminary investigation says that it might be a significant amount of work. Seeing that Nicklas Avén's complaint is the first one we've gotten about this in the ten years or so that the code's been like that, I'm unwilling to put much time into it. Instead, improve the error report by issuing a different message for RETURNING cases, and revise the associated comment based on this investigation. Discussion: 1456176604.17219.9.camel@jordogskog.no 01 March 2016, 00:11:53 UTC
4ef26ff Alvaro Herrera 29 February 2016, 21:11:58 UTC Fix typos Author: Amit Langote 29 February 2016, 21:11:58 UTC
d288054 Alvaro Herrera 29 February 2016, 20:53:55 UTC doc: document MANPATH as /usr/local/pgsql/share/man The docs were advising to use /usr/local/pgsql/man instead, but that's wrong. Reported-By: Slawomir Sudnik Backpatch-To: 9.1 Bug: #13894 29 February 2016, 20:53:55 UTC
0c4457d Tom Lane 29 February 2016, 04:39:20 UTC Avoid multiple free_struct_lconv() calls on same data. A failure partway through PGLC_localeconv() led to a situation where the next call would call free_struct_lconv() a second time, leading to free() on already-freed strings, typically leading to a core dump. Add a flag to remember whether we need to do that. Per report from Thom Brown. His example case only provokes the failure as far back as 9.4, but nonetheless this code is obviously broken, so back-patch to all supported branches. 29 February 2016, 04:40:21 UTC
8fed3cc Tatsuo Ishii 21 February 2016, 00:04:59 UTC Fix wording in the Tutorial document. With suggentions from Tom Lane. 21 February 2016, 00:10:29 UTC
71e3cff Simon Riggs 19 February 2016, 08:33:33 UTC Correct StartupSUBTRANS for page wraparound StartupSUBTRANS() incorrectly handled cases near the max pageid in the subtrans data structure, which in some cases could lead to errors in startup for Hot Standby. This patch wraps the pageids correctly, avoiding any such errors. Identified by exhaustive crash testing by Jeff Janes. Jeff Janes 19 February 2016, 08:33:33 UTC
bf26c4f Bruce Momjian 18 February 2016, 23:32:26 UTC pg_upgrade: suppress creation of delete script Suppress creation of the pg_upgrade delete script when the new data directory is inside the old data directory. Reported-by: IRC Backpatch-through: 9.3, where delete script tests were added 18 February 2016, 23:32:26 UTC
9dfb5b9 Tom Lane 18 February 2016, 20:40:35 UTC Fix multiple bugs in contrib/pgstattuple's pgstatindex() function. Dead or half-dead index leaf pages were incorrectly reported as live, as a consequence of a code rearrangement I made (during a moment of severe brain fade, evidently) in commit d287818eb514d431. The index metapage was not counted in index_size, causing that result to not agree with the actual index size on-disk. Index root pages were not counted in internal_pages, which is inconsistent compared to the case of a root that's also a leaf (one-page index), where the root would be counted in leaf_pages. Aside from that inconsistency, this could lead to additional transient discrepancies between the reported page counts and index_size, since it's possible for pgstatindex's scan to see zero or multiple pages marked as BTP_ROOT, if the root moves due to a split during the scan. With these fixes, index_size will always be exactly one page more than the sum of the displayed page counts. Also, the index_size result was incorrectly documented as being measured in pages; it's always been measured in bytes. (While fixing that, I couldn't resist doing some small additional wordsmithing on the pgstattuple docs.) Including the metapage causes the reported index_size to not be zero for an empty index. To preserve the desired property that the pgstattuple regression test results are platform-independent (ie, BLCKSZ configuration independent), scale the index_size result in the regression tests. The documentation issue was reported by Otsuka Kenji, and the inconsistent root page counting by Peter Geoghegan; the other problems noted by me. Back-patch to all supported branches, because this has been broken for a long time. 18 February 2016, 20:40:35 UTC
b3ec98c Tom Lane 17 February 2016, 02:08:15 UTC Make plpython cope with funny characters in function names. A function name that's double-quoted in SQL can contain almost any characters, but we were using that name directly as part of the name generated for the Python-level function, and Python doesn't like anything that isn't pretty much a standard identifier. To fix, replace anything that isn't an ASCII letter or digit with an underscore in the generated name. This doesn't create any risk of duplicate Python function names because we were already appending the function OID to the generated name to ensure uniqueness. Per bug #13960 from Jim Nasby. Patch by Jim Nasby, modified a bit by me. Back-patch to all supported branches. 17 February 2016, 02:08:15 UTC
0d670b9 Tom Lane 16 February 2016, 18:43:03 UTC Improve documentation about CREATE INDEX CONCURRENTLY. Clarify the description of which transactions will block a CREATE INDEX CONCURRENTLY command from proceeding, and mention that the index might still not be usable after CREATE INDEX completes. (This happens if the index build detected broken HOT chains, so that pg_index.indcheckxmin gets set, and there are open old transactions preventing the xmin horizon from advancing past the index's initial creation. I didn't want to explain what broken HOT chains are, though, so I omitted an explanation of exactly when old transactions prevent the index from being used.) Per discussion with Chris Travers. Back-patch to all supported branches, since the same text appears in all of them. 16 February 2016, 18:43:03 UTC
5043e3a Tatsuo Ishii 16 February 2016, 06:36:52 UTC Improve wording in the planner doc Change "In this case" to "In the example above" to clarify what it actually refers to. 16 February 2016, 06:37:59 UTC
984da96 Fujii Masao 16 February 2016, 05:59:19 UTC Correct the formulas for System V IPC parameters SEMMNI and SEMMNS in docs. In runtime.sgml, the old formulas for calculating the reasonable values of SEMMNI and SEMMNS were incorrect. They have forgotten to count the number of semaphores which both the checkpointer process (introduced in 9.2) and the background worker processes (introduced in 9.3) need. This commit fixes those formulas so that they count the number of semaphores which the checkpointer process and the background worker processes need. Report and patch by Kyotaro Horiguchi. Only the patch for 9.3 was modified by me. Back-patch to 9.2 where the checkpointer process was added and the number of needed semaphores was increased. Author: Kyotaro Horiguchi Reviewed-by: Fujii Masao Backpatch: 9.2 Discussion: http://www.postgresql.org/message-id/20160203.125119.66820697.horiguchi.kyotaro@lab.ntt.co.jp 16 February 2016, 05:59:19 UTC
baa7f63 Alvaro Herrera 15 February 2016, 23:33:43 UTC pgbench: avoid FD_ISSET on an invalid file descriptor The original code wasn't careful to test the file descriptor returned by PQsocket() for an invalid socket. If an invalid socket did turn up, that would amount to calling FD_ISSET with fd = -1, whereby undefined behavior can be invoked. To fix, test file descriptor for validity and stop further processing if that fails. Problem noticed by Coverity. There is an existing FD_ISSET callsite that does check for invalid sockets beforehand, but the error message reported by it was strerror(errno); in testing the aforementioned change, that turns out to result in "bad socket: Success" which isn't terribly helpful. Instead use PQerrorMessage() in both places which is more likely to contain an useful error message. Backpatch-through: 9.1. 15 February 2016, 23:33:43 UTC
e1df791 Tom Lane 15 February 2016, 22:11:52 UTC Suppress compiler warnings about useless comparison of unsigned to zero. Reportedly, some compilers warn about tests like "c < 0" if c is unsigned, and hence complain about the character range checks I added in commit 3bb3f42f3749d40b8d4de65871e8d828b18d4a45. This is a bit of a pain since the regex library doesn't really want to assume that chr is unsigned. However, since any such reconfiguration would involve manual edits of regcustom.h anyway, we can put it on the shoulders of whoever wants to do that to adjust this new range-checking macro correctly. Per gripes from Coverity and Andres. 15 February 2016, 22:11:52 UTC
198242e Noah Misch 11 February 2016, 01:34:02 UTC Accept pg_ctl timeout from the PGCTLTIMEOUT environment variable. Many automated test suites call pg_ctl. Buildfarm members axolotl, hornet, mandrill, shearwater, sungazer and tern have failed when server shutdown took longer than the pg_ctl default 60s timeout. This addition permits slow hosts to easily raise the timeout without us editing a --timeout argument into every test suite pg_ctl call. Back-patch to 9.1 (all supported versions) for the sake of automated testing. Reviewed by Tom Lane. 11 February 2016, 01:34:35 UTC
24ce575 Tom Lane 11 February 2016, 00:30:12 UTC Avoid use of sscanf() to parse ispell dictionary files. It turns out that on FreeBSD-derived platforms (including OS X), the *scanf() family of functions is pretty much brain-dead about multibyte characters. In particular it will apply isspace() to individual bytes of input even when those bytes are part of a multibyte character, thus allowing false recognition of a field-terminating space. We appear to have little alternative other than instituting a coding rule that *scanf() is not to be used if the input string might contain multibyte characters. (There was some discussion of relying on "%ls", but that probably just moves the portability problem somewhere else, and besides it doesn't fully prevent BSD *scanf() from using isspace().) This patch is a down payment on that: it gets rid of use of sscanf() to parse ispell dictionary files, which are certainly at great risk of having a problem. The code is cleaner this way anyway, though a bit longer. In passing, improve a few comments. Report and patch by Artur Zakirov, reviewed and somewhat tweaked by me. Back-patch to all supported branches. 11 February 2016, 00:30:12 UTC
de07063 Tom Lane 08 February 2016, 21:17:25 UTC Stamp 9.3.11. 08 February 2016, 21:17:25 UTC
454994a Peter Eisentraut 08 February 2016, 19:41:41 UTC Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 85e9ea36e147944d4852fe2647c95a26e909bb19 08 February 2016, 19:41:41 UTC
c846576 Tom Lane 08 February 2016, 15:49:38 UTC Last-minute updates for release notes. Security: CVE-2016-0773 08 February 2016, 15:49:38 UTC
6403a6b Tom Lane 08 February 2016, 15:25:40 UTC Fix some regex issues with out-of-range characters and large char ranges. Previously, our regex code defined CHR_MAX as 0xfffffffe, which is a bad choice because it is outside the range of type "celt" (int32). Characters approaching that limit could lead to infinite loops in logic such as "for (c = a; c <= b; c++)" where c is of type celt but the range bounds are chr. Such loops will work safely only if CHR_MAX+1 is representable in celt, since c must advance to beyond b before the loop will exit. Fortunately, there seems no reason not to restrict CHR_MAX to 0x7ffffffe. It's highly unlikely that Unicode will ever assign codes that high, and none of our other backend encodings need characters beyond that either. In addition to modifying the macro, we have to explicitly enforce character range restrictions on the values of \u, \U, and \x escape sequences, else the limit is trivially bypassed. Also, the code for expanding case-independent character ranges in bracket expressions had a potential integer overflow in its calculation of the number of characters it could generate, which could lead to allocating too small a character vector and then overwriting memory. An attacker with the ability to supply arbitrary regex patterns could easily cause transient DOS via server crashes, and the possibility for privilege escalation has not been ruled out. Quite aside from the integer-overflow problem, the range expansion code was unnecessarily inefficient in that it always produced a result consisting of individual characters, abandoning the knowledge that we had a range to start with. If the input range is large, this requires excessive memory. Change it so that the original range is reported as-is, and then we add on any case-equivalent characters that are outside that range. With this approach, we can bound the number of individual characters allowed without sacrificing much. This patch allows at most 100000 individual characters, which I believe to be more than the number of case pairs existing in Unicode, so that the restriction will never be hit in practice. It's still possible for range() to take awhile given a large character code range, so also add statement-cancel detection to its loop. The downstream function dovec() also lacked cancel detection, and could take a long time given a large output from range(). Per fuzz testing by Greg Stark. Back-patch to all supported branches. Security: CVE-2016-0773 08 February 2016, 15:25:40 UTC
abcb32d Tom Lane 07 February 2016, 21:02:44 UTC Improve documentation about PRIMARY KEY constraints. Get rid of the false implication that PRIMARY KEY is exactly equivalent to UNIQUE + NOT NULL. That was more-or-less true at one time in our implementation, but the standard doesn't say that, and we've grown various features (many of them required by spec) that treat a pkey differently from less-formal constraints. Per recent discussion on pgsql-general. I failed to resist the temptation to do some other wordsmithing in the same area. 07 February 2016, 21:02:44 UTC
dd48a39 Tom Lane 07 February 2016, 19:16:32 UTC Release notes for 9.5.1, 9.4.6, 9.3.11, 9.2.15, 9.1.20. 07 February 2016, 19:16:32 UTC
34e9173 Noah Misch 06 February 2016, 01:22:51 UTC Force certain "pljava" custom GUCs to be PGC_SUSET. Future PL/Java versions will close CVE-2016-0766 by making these GUCs PGC_SUSET. This PostgreSQL change independently mitigates that PL/Java vulnerability, helping sites that update PostgreSQL more frequently than PL/Java. Back-patch to 9.1 (all supported versions). 06 February 2016, 01:23:11 UTC
9a3475b Tom Lane 05 February 2016, 15:59:09 UTC Update time zone data files to tzdata release 2016a. DST law changes in Cayman Islands, Metlakatla, Trans-Baikal Territory (Zabaykalsky Krai). Historical corrections for Pakistan. 05 February 2016, 15:59:31 UTC
aefbc20 Tom Lane 04 February 2016, 05:26:10 UTC In pg_dump, ensure that view triggers are processed after view rules. If a view is split into CREATE TABLE + CREATE RULE to break a circular dependency, then any triggers on the view must be dumped/reloaded after the CREATE RULE; else the backend may reject the CREATE TRIGGER because it's the wrong type of trigger for a plain table. This works all right in plain dump/restore because of pg_dump's sorting heuristic that places triggers after rules. However, when using parallel restore, the ordering must be enforced by a dependency --- and we didn't have one. Fixing this is a mere matter of adding an addObjectDependency() call, except that we need to be able to find all the triggers belonging to the view relation, and there was no easy way to do that. Add fields to pg_dump's TableInfo struct to remember where the associated TriggerInfo struct(s) are. Per bug report from Dennis Kögel. The failure can be exhibited at least as far back as 9.1, so back-patch to all supported branches. 04 February 2016, 05:26:10 UTC
014796a Robert Haas 03 February 2016, 14:15:29 UTC pgbench: Install guard against overflow when dividing by -1. Commit 64f5edca2401f6c2f23564da9dd52e92d08b3a20 fixed the same hazard on master; this is a backport, but the modulo operator does not exist in older releases. Michael Paquier 03 February 2016, 14:19:58 UTC
1f2b195 Tom Lane 03 February 2016, 06:39:08 UTC Fix IsValidJsonNumber() to notice trailing non-alphanumeric garbage. Commit e09996ff8dee3f70 was one brick shy of a load: it didn't insist that the detected JSON number be the whole of the supplied string. This allowed inputs such as "2016-01-01" to be misdetected as valid JSON numbers. Per bug #13906 from Dmitry Ryabov. In passing, be more wary of zero-length input (I'm not sure this can happen given current callers, but better safe than sorry), and do some minor cosmetic cleanup. 03 February 2016, 06:39:08 UTC
0b55fef Michael Meskes 01 February 2016, 12:10:40 UTC Make sure ecpg header files do not have a comment lasting several lines, one of which is a preprocessor directive. This leads ecpg to incorrectly parse the comment as nested. 01 February 2016, 12:19:10 UTC
ca5f5c4 Andrew Dunstan 31 January 2016, 00:28:44 UTC Fix error in documentated use of mingw-w64 compilers Error reported by Igal Sapir. 31 January 2016, 00:31:30 UTC
db678ca Tom Lane 29 January 2016, 09:28:03 UTC Fix incorrect pattern-match processing in psql's \det command. listForeignTables' invocation of processSQLNamePattern did not match up with the other ones that handle potentially-schema-qualified names; it failed to make use of pg_table_is_visible() and also passed the name arguments in the wrong order. Bug seems to have been aboriginal in commit 0d692a0dc9f0e532. It accidentally sort of worked as long as you didn't inquire too closely into the behavior, although the silliness was later exposed by inconsistencies in the test queries added by 59efda3e50ca4de6 (which I probably should have questioned at the time, but didn't). Per bug #13899 from Reece Hart. Patch by Reece Hart and Tom Lane. Back-patch to all affected branches. 29 January 2016, 09:28:03 UTC
9bbfca8 Tom Lane 26 January 2016, 20:38:33 UTC Fix startup so that log prefix %h works for the log_connections message. We entirely randomly chose to initialize port->remote_host just after printing the log_connections message, when we could perfectly well do it just before, allowing %h and %r to work for that message. Per gripe from Artem Tomyuk. 26 January 2016, 20:38:33 UTC
7a47262 Bruce Momjian 20 January 2016, 04:30:28 UTC Properly install dynloader.h on MSVC builds This will enable PL/Java to be cleanly compiled, as dynloader.h is a requirement. Report by Chapman Flack Patch by Michael Paquier Backpatch through 9.1 20 January 2016, 04:30:28 UTC
f704f43 Robert Haas 15 January 2016, 04:12:05 UTC Fix spelling mistake. Same patch submitted independently by David Rowley and Peter Geoghegan. 15 January 2016, 04:16:11 UTC
77d8edc Magnus Hagander 14 January 2016, 12:06:03 UTC Properly close token in sspi authentication We can never leak more than one token, but we shouldn't do that. We don't bother closing it in the error paths since the process will exit shortly anyway. Christian Ullrich 14 January 2016, 12:07:45 UTC
b87403f Tom Lane 13 January 2016, 23:55:27 UTC Handle extension members when first setting object dump flags in pg_dump. pg_dump's original approach to handling extension member objects was to run around and clear (or set) their dump flags rather late in its data collection process. Unfortunately, quite a lot of code expects those flags to be valid before that; which was an entirely reasonable expectation before we added extensions. In particular, this explains Karsten Hilbert's recent report of pg_upgrade failing on a database in which an extension has been installed into the pg_catalog schema. Its objects are initially marked as not-to-be-dumped on the strength of their schema, and later we change them to must-dump because we're doing a binary upgrade of their extension; but we've already skipped essential tasks like making associated DO_SHELL_TYPE objects. To fix, collect extension membership data first, and incorporate it in the initial setting of the dump flags, so that those are once again correct from the get-go. This has the undesirable side effect of slightly lengthening the time taken before pg_dump acquires table locks, but testing suggests that the increase in that window is not very much. Along the way, get rid of ugly special-case logic for deciding whether to dump procedural languages, FDWs, and foreign servers; dump decisions for those are now correct up-front, too. In 9.3 and up, this also fixes erroneous logic about when to dump event triggers (basically, they were *always* dumped before). In 9.5 and up, transform objects had that problem too. Since this problem came in with extensions, back-patch to all supported versions. 13 January 2016, 23:55:27 UTC
0ddeaba Tom Lane 12 January 2016, 00:55:40 UTC Avoid dump/reload problems when using both plpython2 and plpython3. Commit 803716013dc1350f installed a safeguard against loading plpython2 and plpython3 at the same time, but asserted that both could still be used in the same database, just not in the same session. However, that's not actually all that practical because dumping and reloading will fail (since both libraries necessarily get loaded into the restoring session). pg_upgrade is even worse, because it checks for missing libraries by loading every .so library mentioned in the entire installation into one session, so that you can have only one across the whole cluster. We can improve matters by not throwing the error immediately in _PG_init, but only when and if we're asked to do something that requires calling into libpython. This ameliorates both of the above situations, since while execution of CREATE LANGUAGE, CREATE FUNCTION, etc will result in loading plpython, it isn't asked to do anything interesting (at least not if check_function_bodies is off, as it will be during a restore). It's possible that this opens some corner-case holes in which a crash could be provoked with sufficient effort. However, since plpython only exists as an untrusted language, any such crash would require superuser privileges, making it "don't do that" not a security issue. To reduce the hazards in this area, the error is still FATAL when it does get thrown. Per a report from Paul Jones. Back-patch to 9.2, which is as far back as the patch applies without work. (It could be made to work in 9.1, but given the lack of previous complaints, I'm disinclined to expend effort so far back. We've been pretty desultory about support for Python 3 in 9.1 anyway.) 12 January 2016, 00:55:40 UTC
8b5cc3e Tom Lane 09 January 2016, 21:58:32 UTC Clean up some lack-of-STRICT issues in the core code, too. A scan for missed proisstrict markings in the core code turned up these functions: brin_summarize_new_values pg_stat_reset_single_table_counters pg_stat_reset_single_function_counters pg_create_logical_replication_slot pg_create_physical_replication_slot pg_drop_replication_slot The first three of these take OID, so a null argument will normally look like a zero to them, resulting in "ERROR: could not open relation with OID 0" for brin_summarize_new_values, and no action for the pg_stat_reset_XXX functions. The other three will dump core on a null argument, though this is mitigated by the fact that they won't do so until after checking that the caller is superuser or has rolreplication privilege. In addition, the pg_logical_slot_get/peek[_binary]_changes family was intentionally marked nonstrict, but failed to make nullness checks on all the arguments; so again a null-pointer-dereference crash is possible but only for superusers and rolreplication users. Add the missing ARGISNULL checks to the latter functions, and mark the former functions as strict in pg_proc. Make that change in the back branches too, even though we can't force initdb there, just so that installations initdb'd in future won't have the issue. Since none of these bugs rise to the level of security issues (and indeed the pg_stat_reset_XXX functions hardly misbehave at all), it seems sufficient to do this. In addition, fix some order-of-operations oddities in the slot_get_changes family, mostly cosmetic, but not the part that moves the function's last few operations into the PG_TRY block. As it stood, there was significant risk for an error to exit without clearing historical information from the system caches. The slot_get_changes bugs go back to 9.4 where that code was introduced. Back-patch appropriate subsets of the pg_proc changes into all active branches, as well. 09 January 2016, 21:58:32 UTC
23382c4 Tom Lane 09 January 2016, 18:44:27 UTC Clean up code for widget_in() and widget_out(). Given syntactically wrong input, widget_in() could call atof() with an indeterminate pointer argument, typically leading to a crash; or if it didn't do that, it might return a NULL pointer, which again would lead to a crash since old-style C functions aren't supposed to do things that way. Fix that by correcting the off-by-one syntax test and throwing a proper error rather than just returning NULL. Also, since widget_in and widget_out have been marked STRICT for a long time, their tests for null inputs are just dead code; remove 'em. In the oldest branches, also improve widget_out to use snprintf not sprintf, just to be sure. In passing, get rid of a long-since-useless sprintf into a local buffer that nothing further is done with, and make some other minor coding style cleanups. In the intended regression-testing usage of these functions, none of this is very significant; but if the regression test database were left around in a production installation, these bugs could amount to a minor security hazard. Piotr Stefaniak, Michael Paquier, and Tom Lane 09 January 2016, 18:44:27 UTC
f2c6804 Tom Lane 09 January 2016, 18:02:54 UTC Add STRICT to some C functions created by the regression tests. These functions readily crash when passed a NULL input value. The tests themselves do not pass NULL values to them; but when the regression database is used as a basis for fuzz testing, they cause a lot of noise. Also, if someone were to leave a regression database lying about in a production installation, these would create a minor security hazard. Andreas Seltenreich 09 January 2016, 18:03:19 UTC
back to top