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
105f3ef Alvaro Herrera 20 January 2015, 15:26:20 UTC Disable -faggressive-loop-optimizations in gcc 4.8+ for pre-9.2 branches. With this optimization flag enabled, recent versions of gcc can generate incorrect code that assumes variable-length arrays (such as oidvector) are actually fixed-length because they're embedded in some larger struct. The known instance of this problem was fixed in 9.2 and up by commit 8137f2c32322c624e0431fac1621e8e9315202f9 and followon work, which hides actually-variable-length catalog fields from the compiler altogether. And we plan to gradually convert variable-length fields to official "flexible array member" notation over time, which should prevent this type of bug from reappearing as gcc gets smarter. We're not going to try to back-port those changes into older branches, though, so apply this band-aid instead. Andres Freund This is a backpatch of commit 649839dd9 to unsupported branches REL8_2_STABLE and REL8_3_STABLE, so that they work with newer toolsets. 20 January 2015, 15:26:20 UTC
91a1e14 Andrew Dunstan 14 December 2011, 22:05:12 UTC Disable excessive FP optimization by recent versions of gcc. Suggested solution from Tom Lane. Problem discovered, probably not for the first time, while testing the mingw-w64 32 bit compiler. Backpatched to all live branches. 14 December 2011, 22:05:12 UTC
fa1369a Tom Lane 01 December 2011, 21:59:19 UTC Stamp 8.2.23. Hail and farewell, 8.2. 01 December 2011, 21:59:19 UTC
0564f62 Tom Lane 01 December 2011, 01:55:22 UTC Update information about configuring SysV IPC parameters on NetBSD. Per Emmanuel Kasper, sysctl works fine as of NetBSD 5.0. 01 December 2011, 01:55:22 UTC
d3050de Tom Lane 01 December 2011, 00:35:10 UTC Draft release notes for 9.1.2, 9.0.6, 8.4.10, 8.3.17, 8.2.23. 01 December 2011, 00:35:10 UTC
122d05e Tom Lane 30 November 2011, 16:48:05 UTC Update time zone data files to tzdata release 2011n. DST law changes in Brazil, Cuba, Fiji, Palestine, Russia, Samoa. Historical corrections for Alaska and British East Africa. 30 November 2011, 16:49:21 UTC
f97aaaa Tom Lane 30 November 2011, 05:37:38 UTC Tweak previous patch to ensure edata->filename always gets initialized. On a platform that isn't supplying __FILE__, previous coding would either crash or give a stale result for the filename string. Not sure how likely that is, but the original code catered for it, so let's keep doing so. 30 November 2011, 05:37:38 UTC
1a44811 Peter Eisentraut 29 November 2011, 20:04:59 UTC Strip file names reported in error messages in vpath builds In vpath builds, the __FILE__ macro that is used in verbose error reports contains the full absolute file name, which makes the error messages excessively verbose. So keep only the base name, thus matching the behavior of non-vpath builds. 30 November 2011, 04:47:03 UTC
e53724f Andrew Dunstan 28 November 2011, 12:46:47 UTC Backpatch "Use the preferred version of xsubpp." As requested this is backpatched all the way to release 8.2. 28 November 2011, 12:46:47 UTC
d2202a6 Robert Haas 16 November 2011, 01:34:47 UTC Don't elide blank lines when accumulating psql command history. This can change the meaning of queries, if the blank line happens to occur in the middle of a quoted literal, as per complaint from Tomas Vondra. Back-patch to all supported branches. 16 November 2011, 01:36:32 UTC
003fae7 Peter Eisentraut 10 November 2011, 18:52:54 UTC Fix server header file installation with vpath builds Several server header files would not be installed in vpath builds because they live in the build directory. 10 November 2011, 19:42:00 UTC
73e8ee9 Tom Lane 05 November 2011, 03:23:38 UTC Don't assume that a tuple's header size is unchanged during toasting. This assumption can be wrong when the toaster is passed a raw on-disk tuple, because the tuple might pre-date an ALTER TABLE ADD COLUMN operation that added columns without rewriting the table. In such a case the tuple's natts value is smaller than what we expect from the tuple descriptor, and so its t_hoff value could be smaller too. In fact, the tuple might not have a null bitmap at all, and yet our current opinion of it is that it contains some trailing nulls. In such a situation, toast_insert_or_update did the wrong thing, because to save a few lines of code it would use the old t_hoff value as the offset where heap_fill_tuple should start filling data. This did not leave enough room for the new nulls bitmap, with the result that the first few bytes of data could be overwritten with null flag bits, as in a recent report from Hubert Depesz Lubaczewski. The particular case reported requires ALTER TABLE ADD COLUMN followed by CREATE TABLE AS SELECT * FROM ... or INSERT ... SELECT * FROM ..., and further requires that there be some out-of-line toasted fields in one of the tuples to be copied; else we'll not reach the troublesome code. The problem can only manifest in this form in 8.4 and later, because before commit a77eaa6a95009a3441e0d475d1980259d45da072, CREATE TABLE AS or INSERT/SELECT wouldn't result in raw disk tuples getting passed directly to heap_insert --- there would always have been at least a junkfilter in between, and that would reconstitute the tuple header with an up-to-date t_natts and hence t_hoff. But I'm backpatching the tuptoaster change all the way anyway, because I'm not convinced there are no older code paths that present a similar risk. 05 November 2011, 03:23:38 UTC
b24e6ca Tom Lane 01 November 2011, 23:49:06 UTC Fix race condition with toast table access from a stale syscache entry. If a tuple in a syscache contains an out-of-line toasted field, and we try to fetch that field shortly after some other transaction has committed an update or deletion of the tuple, there is a race condition: vacuum could come along and remove the toast tuples before we can fetch them. This leads to transient failures like "missing chunk number 0 for toast value NNNNN in pg_toast_2619", as seen in recent reports from Andrew Hammond and Tim Uckun. The design idea of syscache is that access to stale syscache entries should be prevented by relation-level locks, but that fails for at least two cases where toasted fields are possible: ANALYZE updates pg_statistic rows without locking out sessions that might want to plan queries on the same table, and CREATE OR REPLACE FUNCTION updates pg_proc rows without any meaningful lock at all. The least risky fix seems to be an idea that Heikki suggested when we were dealing with a related problem back in August: forcibly detoast any out-of-line fields before putting a tuple into syscache in the first place. This avoids the problem because at the time we fetch the parent tuple from the catalog, we should be holding an MVCC snapshot that will prevent removal of the toast tuples, even if the parent tuple is outdated immediately after we fetch it. (Note: I'm not convinced that this statement holds true at every instant where we could be fetching a syscache entry at all, but it does appear to hold true at the times where we could fetch an entry that could have a toasted field. We will need to be a bit wary of adding toast tables to low-level catalogs that don't have them already.) An additional benefit is that subsequent uses of the syscache entry should be faster, since they won't have to detoast the field. Back-patch to all supported versions. The problem is significantly harder to reproduce in pre-9.0 releases, because of their willingness to flush every entry in a syscache whenever the underlying catalog is vacuumed (cf CatalogCacheFlushRelation); but there is still a window for trouble. 01 November 2011, 23:49:06 UTC
5b297de Tom Lane 29 October 2011, 18:31:15 UTC Fix assorted bogosities in cash_in() and cash_out(). cash_out failed to handle multiple-byte thousands separators, as per bug #6277 from Alexander Law. In addition, cash_in didn't handle that either, nor could it handle multiple-byte positive_sign. Both routines failed to support multiple-byte mon_decimal_point, which I did not think was worth changing, but at least now they check for the possibility and fall back to using '.' rather than emitting invalid output. Also, make cash_in handle trailing negative signs, which formerly it would reject. Since cash_out generates trailing negative signs whenever the locale tells it to, this last omission represents a fail-to-reload-dumped-data bug. IMO that justifies patching this all the way back. 29 October 2011, 18:31:15 UTC
7208e0b Tom Lane 28 October 2011, 03:09:30 UTC Update docs to point to the timezone library's new home at IANA. The recent unpleasantness with copyrights has accelerated a move that was already in planning. 28 October 2011, 03:09:30 UTC
1f897ae Tom Lane 26 October 2011, 17:02:58 UTC Change FK trigger creation order to better support self-referential FKs. When a foreign-key constraint references another column of the same table, row updates will queue both the PK's ON UPDATE action and the FK's CHECK action in the same event. The ON UPDATE action must execute first, else the CHECK will check a non-final state of the row and possibly throw an inappropriate error, as seen in bug #6268 from Roman Lytovchenko. Now, the firing order of multiple triggers for the same event is determined by the sort order of their pg_trigger.tgnames, and the auto-generated names we use for FK triggers are "RI_ConstraintTrigger_NNNN" where NNNN is the trigger OID. So most of the time the firing order is the same as creation order, and so rearranging the creation order fixes it. This patch will fail to fix the problem if the OID counter wraps around or adds a decimal digit (eg, from 99999 to 100000) while we are creating the triggers for an FK constraint. Given the small odds of that, and the low usage of self-referential FKs, we'll live with that solution in the back branches. A better fix is to change the auto-generated names for FK triggers, but it seems unwise to do that in stable branches because there may be client code that depends on the naming convention. We'll fix it that way in HEAD in a separate patch. Back-patch to all supported branches, since this bug has existed for a long time. 26 October 2011, 17:02:58 UTC
9a743ff Tom Lane 15 October 2011, 00:24:57 UTC Fix bugs in information_schema.referential_constraints view. This view was being insufficiently careful about matching the FK constraint to the depended-on primary or unique key constraint. That could result in failure to show an FK constraint at all, or showing it multiple times, or claiming that it depended on a different constraint than the one it really does. Fix by joining via pg_depend to ensure that we find only the correct dependency. Back-patch, but don't bump catversion because we can't force initdb in back branches. The next minor-version release notes should explain that if you need to fix this in an existing installation, you can drop the information_schema schema then re-create it by sourcing $SHAREDIR/information_schema.sql in each database (as a superuser of course). 15 October 2011, 00:24:57 UTC
7a0c584 Tom Lane 12 October 2011, 17:59:30 UTC Improve documentation of psql's \q command. The documentation neglected to explain its behavior in a script file (it only ends execution of the script, not psql as a whole), and failed to mention the long form \quit either. 12 October 2011, 18:00:23 UTC
aadfd6e Heikki Linnakangas 08 October 2011, 08:17:40 UTC Don't let transform_null_equals=on affect CASE foo WHEN NULL ... constructs. transform_null_equals is only supposed to affect "foo = NULL" expressions given directly by the user, not the internal "foo = NULL" expression generated from CASE-WHEN. This fixes bug #6242, reported by Sergey. Backpatch to all supported branches. 08 October 2011, 08:21:16 UTC
b6959ee Robert Haas 06 October 2011, 16:08:59 UTC Make pgstatindex respond to cancel interrupts. A similar problem for pgstattuple() was fixed in April of 2010 by commit 33065ef8bc52253ae855bc959576e52d8a28ba06, but pgstatindex() seems to have been overlooked. Back-patch all the way, as with that commit, though not to 7.4 through 8.1, since those are now EOL. 06 October 2011, 16:11:30 UTC
6f4f000 Tom Lane 24 September 2011, 02:12:36 UTC Fix our mapping of Windows timezones for Central America. We were mapping "Central America Standard Time" to "CST6CDT", which seems entirely wrong, because according to the Olson timezone database noplace in Central America observes daylight savings time on any regular basis --- and certainly not according to the USA DST rules that are implied by "CST6CDT". (Mexico is an exception, but they can be disregarded since they have a separate timezone name in Windows.) So, map this zone name to plain "CST6", which will provide a fixed UTC offset. As written, this patch will also result in mapping "Central America Daylight Time" to CST6. I considered hacking things so that would still map to CST6CDT, but it seems it would confuse win32tzlist.pl to put those two names in separate entries. Since there's little evidence that any such zone name is used in the wild, much less that CST6CDT would be a good match for it, I'm not too worried about what we do with it. Per complaint from Pratik Chirania. 24 September 2011, 02:14:23 UTC
d08aa19 Tom Lane 22 September 2011, 22:09:27 UTC Stamp 8.2.22. 22 September 2011, 22:09:27 UTC
3a15399 Tom Lane 22 September 2011, 21:39:43 UTC Update release notes for 9.1.1, 9.0.5, 8.4.9, 8.3.16, 8.2.22. Man, we fixed a lotta bugs since April. 22 September 2011, 21:40:39 UTC
7b93bbb Peter Eisentraut 22 September 2011, 18:59:26 UTC Translation updates 22 September 2011, 18:59:26 UTC
ca00f19 Tom Lane 16 September 2011, 08:28:15 UTC gistendscan() forgot to free so->giststate. This oversight led to a massive memory leak --- upwards of 10KB per tuple --- during creation-time verification of an exclusion constraint based on a GIST index. In most other scenarios it'd just be a leak of 10KB that would be recovered at end of query, so not too significant; though perhaps the leak would be noticeable in a situation where a GIST index was being used in a nestloop inner indexscan. In any case, it's a real leak of long standing, so patch all supported branches. Per report from Harald Fuchs. 16 September 2011, 08:28:15 UTC
33e111f Peter Eisentraut 08 September 2011, 19:09:08 UTC Add missing format argument to ecpg_log() call 08 September 2011, 19:15:53 UTC
eb9a98b Tom Lane 07 September 2011, 21:06:44 UTC Fix corner case bug in numeric to_char(). Trailing-zero stripping applied by the FM specifier could strip zeroes to the left of the decimal point, for a format with no digit positions after the decimal point (such as "FM999."). Reported and diagnosed by Marti Raudsepp, though I didn't use his patch. 07 September 2011, 21:06:44 UTC
8036097 Tom Lane 06 September 2011, 18:36:01 UTC Avoid possibly accessing off the end of memory in examine_attribute(). Since the last couple of columns of pg_type are often NULL, sizeof(FormData_pg_type) can be an overestimate of the actual size of the tuple data part. Therefore memcpy'ing that much out of the catalog cache, as analyze.c was doing, poses a small risk of copying past the end of memory and incurring SIGSEGV. No such crash has been identified in the field, but we've certainly seen the equivalent happen in other code paths, so patch this one all the way back. Per valgrind testing by Noah Misch, though this is not his proposed patch. I chose to use SearchSysCacheCopy1 rather than inventing special-purpose infrastructure for copying only the minimal part of a pg_type tuple. 06 September 2011, 18:38:21 UTC
1426abb Tom Lane 06 September 2011, 16:14:51 UTC Update type-conversion documentation for long-ago changes. This example wasn't updated when we changed the behavior of bpcharlen() in 8.0, nor when we changed the number of parameters taken by the bpchar() cast function in 7.3. Per report from lsliang. 06 September 2011, 16:15:23 UTC
c2042d0 Tom Lane 05 September 2011, 18:46:31 UTC Update time zone data files to tzdata release 2011i. DST law changes in Canada, Egypt, Russia, Samoa, South Sudan. 05 September 2011, 18:48:04 UTC
f655a9f Tom Lane 03 September 2011, 20:18:01 UTC Fix typo in pg_srand48 (srand48 in older branches). ">" should be ">>". This typo results in failure to use all of the bits of the provided seed. This might rise to the level of a security bug if we were relying on srand48 for any security-critical purposes, but we are not --- in fact, it's not used at all unless the platform lacks srandom(), which is improbable. Even on such a platform the exposure seems minimal. Reported privately by Andres Freund. 03 September 2011, 20:18:01 UTC
cbd5154 Tom Lane 29 August 2011, 23:52:13 UTC Replace obsolete AC_LANG_FUNC_LINK_TRY autoconf macro. The version of this macro used in autoconf 2.59 is capable of incorrectly succeeding (ie, reporting that a library function is available when it isn't), if the compiler performs link-time optimization and decides that it can optimize the function reference away entirely. Replace it with the coding used in autoconf 2.61 and later, which forces the program result to depend on the function's result so that it cannot be optimized away. This should fix build failures currently being seen on buildfarm member anchovy. This patch affects the 8.2 and 8.3 branches only, since later branches are using autoconf versions that don't have this problem. 29 August 2011, 23:52:13 UTC
a2d9f94 Tom Lane 27 August 2011, 20:37:22 UTC Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server. These days, such a response is far more likely to signify a server-side problem, such as fork failure. Reporting "server does not support SSL" (in sslmode=require) could be quite misleading. But the results could be even worse in sslmode=prefer: if the problem was transient and the next connection attempt succeeds, we'll have silently fallen back to protocol version 2.0, possibly disabling features the user needs. Hence, it seems best to just eliminate the assumption that backing off to non-SSL/2.0 protocol is the way to recover from an "E" response, and instead treat the server error the same as we would in non-SSL cases. I tested this change against a pre-7.0 server, and found that there was a second logic bug in the "prefer" path: the test to decide whether to make a fallback connection attempt assumed that we must have opened conn->ssl, which in fact does not happen given an "E" response. After fixing that, the code does indeed connect successfully to pre-7.0, as long as you didn't set sslmode=require. (If you did, you get "Unsupported frontend protocol", which isn't completely off base given the server certainly doesn't support SSL.) Since there seems no reason to believe that pre-7.0 servers exist anymore in the wild, back-patch to all supported branches. 27 August 2011, 20:37:22 UTC
bb42ad1 Tom Lane 27 August 2011, 18:16:39 UTC Ensure we discard unread/unsent data when abandoning a connection attempt. There are assorted situations wherein PQconnectPoll() will abandon a connection attempt and try again with different parameters (eg, SSL versus not SSL). However, the code forgot to discard any pending data in libpq's I/O buffers when doing this. In at least one case (server returns E message during SSL negotiation), there is unread input data which bollixes the next connection attempt. I have not checked to see whether this is possible in the other cases where we close the socket and retry, but it seems like a matter of good defensive programming to add explicit buffer-flushing code to all of them. This is one of several issues exposed by Daniel Farina's report of misbehavior after a server-side fork failure. This has been wrong since forever, so back-patch to all supported branches. 27 August 2011, 18:16:39 UTC
ae42744 Tom Lane 25 August 2011, 03:50:36 UTC Fix pgstatindex() to give consistent results for empty indexes. For an empty index, the pgstatindex() function would compute 0.0/0.0 for its avg_leaf_density and leaf_fragmentation outputs. On machines that follow the IEEE float arithmetic standard with any care, that results in a NaN. However, per report from Rushabh Lathia, Microsoft couldn't manage to get this right, so you'd get a bizarre error on Windows. Fix by forcing the results to be NaN explicitly, rather than relying on the division operator to give that or the snprintf function to print it correctly. I have some doubts that this is really the most useful definition, but it seems better to remain backward-compatible with those platforms for which the behavior wasn't completely broken. Back-patch to 8.2, since the code is like that in all current releases. 25 August 2011, 03:50:36 UTC
6016005 Tom Lane 20 August 2011, 18:51:02 UTC Fix performance problem when building a lossy tidbitmap. As pointed out by Sergey Koposov, repeated invocations of tbm_lossify can make building a large tidbitmap into an O(N^2) operation. To fix, make sure we remove more than the minimum amount of information per call, and add a fallback path to behave sanely if we're unable to fit the bitmap within the requested amount of memory. This has been wrong since the tidbitmap code was written, so back-patch to all supported branches. 20 August 2011, 18:51:52 UTC
44631ee Tom Lane 16 August 2011, 17:12:29 UTC Fix race condition in relcache init file invalidation. The previous code tried to synchronize by unlinking the init file twice, but that doesn't actually work: it leaves a window wherein a third process could read the already-stale init file but miss the SI messages that would tell it the data is stale. The result would be bizarre failures in catalog accesses, typically "could not read block 0 in file ..." later during startup. Instead, hold RelCacheInitLock across both the unlink and the sending of the SI messages. This is more straightforward, and might even be a bit faster since only one unlink call is needed. This has been wrong since it was put in (in 2002!), so back-patch to all supported releases. 16 August 2011, 17:12:29 UTC
443a44b Heikki Linnakangas 02 August 2011, 07:47:17 UTC Avoid integer overflow when LIMIT + OFFSET >= 2^63. This fixes bug #6139 reported by Hitoshi Harada. 02 August 2011, 08:31:55 UTC
8daf82e Tom Lane 28 July 2011, 18:07:28 UTC Fix pg_restore's direct-to-database mode for standard_conforming_strings. pg_backup_db.c contained a mini SQL lexer with which it tried to identify boundaries between SQL commands, but that code was not designed to cope with standard_conforming_strings, and would get the wrong answer if a backslash immediately precedes a closing single quote in such a string, as per report from Julian Mehnle. The bug only affects direct-to-database restores from archive files made with standard_conforming_strings = on. Rather than complicating the code some more to try to fix that, let's just rip it all out. The only reason it was needed was to cope with COPY data embedded into ordinary archive entries, which was a layout that was used only for about the first three weeks of the archive format's existence, and never in any production release of pg_dump. Instead, just rely on the archive file layout to tell us whether we're printing COPY data or not. This bug represents a data corruption hazard in all releases in which standard_conforming_strings can be turned on, ie 8.2 and later, so back-patch to all supported branches. 28 July 2011, 18:07:28 UTC
c4222d3 Peter Eisentraut 26 July 2011, 20:24:57 UTC Add missing newlines at end of error messages 26 July 2011, 20:24:57 UTC
a5b0d95 Tom Lane 24 July 2011, 19:18:16 UTC Use OpenSSL's SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER flag. This disables an entirely unnecessary "sanity check" that causes failures in nonblocking mode, because OpenSSL complains if we move or compact the write buffer. The only actual requirement is that we not modify pending data once we've attempted to send it, which we don't. Per testing and research by Martin Pihlak, though this fix is a lot simpler than his patch. I put the same change into the backend, although it's less clear whether it's necessary there. We do use nonblock mode in some situations in streaming replication, so seems best to keep the same behavior in the backend as in libpq. Back-patch to all supported releases. 24 July 2011, 19:18:16 UTC
18e52ae Michael Meskes 18 July 2011, 17:22:03 UTC Adapted expected result for latest change to ecpglib. 18 July 2011, 17:22:03 UTC
e9a1a0d Michael Meskes 18 July 2011, 14:30:51 UTC Made ecpglib write double with a precision of 15 digits. Patch by Akira Kurosawa <kurosawa-akira@mxc.nes.nec.co.jp>. 18 July 2011, 14:34:24 UTC
e2bf629 Heikki Linnakangas 15 July 2011, 07:54:56 UTC Fix two ancient bugs in GiST code to re-find a parent after page split: First, when following a right-link, we incorrectly marked the current page as the parent of the right sibling. In reality, the parent of the right page is the same as the parent of the current page (or some page to the right of it, gistFindCorrectParent() will sort that out). Secondly, when we follow a right-link, we must prepend, not append, the right page to our list of pages to visit. That's because we assume that once we hit a leaf page in the list, all the rest are leaf pages too, and give up. To hit these bugs, you need concurrent actions and several unlucky accidents. Another backend must split the root page, while you're in process of splitting a lower-level page. Furthermore, while you scan the internal nodes to re-find the parent, another backend needs to again split some more internal pages. Even then, the bugs don't necessarily manifest as user-visible errors or index corruption. While we're at it, make the error reporting a bit better if gistFindPath() fails to re-find the parent. It used to be an assertion, but an elog() seems more appropriate. Backpatch to all supported branches. 15 July 2011, 08:06:12 UTC
335a00a Peter Eisentraut 11 July 2011, 16:07:26 UTC Remove excessively backpatched gitignore files These caused directories from future releases to appear in the backbranch tree. 11 July 2011, 16:07:26 UTC
71a4368 Tom Lane 05 July 2011, 16:04:40 UTC Fix psql's counting of script file line numbers during COPY. handleCopyIn incremented pset.lineno for each line of COPY data read from a file. This is correct when reading from the current script file (i.e., we are doing COPY FROM STDIN followed by in-line data), but it's wrong if the data is coming from some other file. Per bug #6083 from Steve Haslam. Back-patch to all supported versions. 05 July 2011, 16:07:03 UTC
41fd969 Tom Lane 03 July 2011, 20:40:37 UTC Back-patch creation of tar.bz2 tarball during "make dist". Since commit a4d03bbcdaf7739d7e9073ee76bb186f68ddc163, "make dist" has built both gzip- and bzip2-compressed tarballs. However, this was pretty useless, because our tarball build script didn't know about it and proceeded to overwrite the bz2 file with new data. Back-patch the change to all active branches, so that creation of the tar.bz2 file can be removed from the build script. 03 July 2011, 20:40:37 UTC
457c2d9 Tom Lane 21 June 2011, 18:41:05 UTC Apply upstream fix for blowfish signed-character bug (CVE-2011-2483). A password containing a character with the high bit set was misprocessed on machines where char is signed (which is most). This could cause the preceding one to three characters to fail to affect the hashed result, thus weakening the password. The result was also unportable, and failed to match some other blowfish implementations such as OpenBSD's. Since the fix changes the output for such passwords, upstream chose to provide a compatibility hack: password salts beginning with $2x$ (instead of the usual $2a$ for blowfish) are intentionally processed "wrong" to give the same hash as before. Stored password hashes can thus be modified if necessary to still match, though it'd be better to change any affected passwords. In passing, sync a couple other upstream changes that marginally improve performance and/or tighten error checking. Back-patch to all supported branches. Since this issue is already public, no reason not to commit the fix ASAP. 21 June 2011, 18:42:34 UTC
66cab2b Tom Lane 20 June 2011, 20:27:51 UTC Fix missed use of "cp -i" in an example, per Fujii Masao. Also be more careful about markup: use &amp; not just &. 20 June 2011, 20:27:51 UTC
26996cf Tom Lane 17 June 2011, 23:13:25 UTC Don't use "cp -i" in the example WAL archive_command. This is a dangerous example to provide because on machines with GNU cp, it will silently do the wrong thing and risk archive corruption. Worse, during the 9.0 cycle somebody "improved" the discussion by removing the warning that used to be there about that, and instead leaving the impression that the command would work as desired on most Unixen. It doesn't. Try to rectify the damage by providing an example that is safe most everywhere, and then noting that you can try cp -i if you want but you'd better test that. In back-patching this to all supported branches, I also added an example command for Windows, which wasn't provided before 9.0. 17 June 2011, 23:13:25 UTC
6c320b8 Tom Lane 17 June 2011, 22:19:31 UTC Obtain table locks as soon as practical during pg_dump. For some reason, when we (I) added table lock acquisition to pg_dump, we didn't think about making it happen as soon as possible after the start of the transaction. What with subsequent additions, there was actually quite a lot going on before we got around to that; which sort of defeats the purpose. Rearrange the order of calls in dumpSchema() to close the risk window as much as we easily can. Back-patch to all supported branches. 17 June 2011, 22:19:31 UTC
199d449 Robert Haas 17 June 2011, 18:28:45 UTC Add overflow checks to int4 and int8 versions of generate_series(). The previous code went into an infinite loop after overflow. In fact, an overflow is not really an error; it just means that the current value is the last one we need to return. So, just arrange to stop immediately when overflow is detected. Back-patch all the way. 17 June 2011, 18:33:03 UTC
07bc6fe Tom Lane 14 June 2011, 21:14:11 UTC Suppress -arch switches in the output of ExtUtils::Embed. We previously found out that OS X's standard perl installation tries to put -arch switches into Perl link commands, evidently in hopes of building universal binaries. But it doesn't work to add such switches in plperl's link step if they weren't being used earlier, so this is basically unworkable. When using gcc the result is only some warnings; but LLVM fails entirely, so this issue isn't as cosmetic as we originally thought. Hence, back-patch commit d69a419e682c2d39c2355105a7e5e2b90357c8f0 into pre-9.0 branches. 14 June 2011, 21:14:11 UTC
1f5e6cd Tom Lane 14 June 2011, 20:39:47 UTC Fix assorted issues with build and install paths containing spaces. Apparently there is no buildfarm critter exercising this case after all, because it fails in several places. With this patch, build, install, check-world, and installcheck-world pass for me on OS X. 14 June 2011, 20:39:47 UTC
8f1eaf8 Alvaro Herrera 13 June 2011, 21:50:30 UTC Fix aboriginal copy-paste mistake in error message Spotted by Jaime Casanova 13 June 2011, 21:50:30 UTC
0f452e8 Tom Lane 10 June 2011, 21:03:27 UTC Work around gcc 4.6.0 bug that breaks WAL replay. ReadRecord's habit of using both direct references to tmpRecPtr and references to *RecPtr (which is pointing at tmpRecPtr) triggers an optimization bug in gcc 4.6.0, which apparently has forgotten about aliasing rules. Avoid the compiler bug, and make the code more readable to boot, by getting rid of the direct references. Improve the comments while at it. Back-patch to all supported versions, in case they get built with 4.6.0. Tom Lane, with some cosmetic suggestions from Alex Hunsaker 10 June 2011, 21:03:27 UTC
e5b50d0 Peter Eisentraut 09 June 2011, 04:24:14 UTC Fix documentation of information_schema.element_types The documentation of the columns collection_type_identifier and dtd_identifier was wrong. This effectively reverts commits 8e1ccad51901e83916dae297cd9afa450957a36c and 57352df66d3a0885899d39c04c067e63c7c0ba30 and updates the name array_type_identifier (the name in SQL:1999) to collection_type_identifier. closes bug #5926 09 June 2011, 04:38:14 UTC
f604891 Andrew Dunstan 04 June 2011, 23:37:50 UTC Allow building with perl 5.14. Patch from Alex Hunsaker. 04 June 2011, 23:37:50 UTC
b9544a0 Peter Eisentraut 04 June 2011, 19:29:26 UTC ECPG documentation fixes Marc Cousin 04 June 2011, 19:53:30 UTC
eb6af64 Tom Lane 04 June 2011, 19:48:41 UTC Expose the "*VALUES*" alias that we generate for a stand-alone VALUES list. We were trying to make that strictly an internal implementation detail, but it turns out that it's exposed anyway when dumping a view defined like CREATE VIEW test_view AS VALUES (1), (2), (3) ORDER BY 1; This comes out as CREATE VIEW ... ORDER BY "*VALUES*".column1; which fails to parse when reloading the dump. Hacking ruleutils.c to suppress the column qualification looks like it'd be a risky business, so instead promote the RTE alias to full-fledged usability. Per bug #6049 from Dylan Adams. Back-patch to all supported branches. 04 June 2011, 19:48:41 UTC
f0d72ef Tom Lane 02 June 2011, 19:31:28 UTC Clean up after erroneous SELECT FOR UPDATE/SHARE on a sequence. My previous commit disallowed this operation, but did nothing about cleaning up the damage if one had already been done. With the operation disallowed, it's okay to just forcibly clear xmax in a sequence's tuple, since any value seen there could not represent a live transaction's lock. So, any sequence-specific operation will repair the problem automatically, whether or not the user has already seen "could not access status of transaction" failures. 02 June 2011, 19:31:28 UTC
a12899e Tom Lane 02 June 2011, 18:46:37 UTC Disallow SELECT FOR UPDATE/SHARE on sequences. We can't allow this because such an operation stores its transaction XID into the sequence tuple's xmax. Because VACUUM doesn't process sequences (and we don't want it to start doing so), such an xmax value won't get frozen, meaning it will eventually refer to nonexistent pg_clog storage, and even wrap around completely. Since the row lock is ignored by nextval and setval, the usefulness of the operation is highly debatable anyway. Per reports of trouble with pgpool 3.0, which had ill-advisedly started using such commands as a form of locking. In HEAD, also disallow SELECT FOR UPDATE/SHARE on toast tables. Although this does work safely given the current implementation, there seems no good reason to allow it. I refrained from changing that behavior in back branches, however. 02 June 2011, 18:46:37 UTC
08779dc Tom Lane 31 May 2011, 21:54:11 UTC Protect GIST logic that assumes penalty values can't be negative. Apparently sane-looking penalty code might return small negative values, for example because of roundoff error. This will confuse places like gistchoose(). Prevent problems by clamping negative penalty values to zero. (Just to be really sure, I also made it force NaNs to zero.) Back-patch to all supported branches. Alexander Korotkov 31 May 2011, 21:54:11 UTC
fccef77 Tom Lane 30 May 2011, 23:16:28 UTC Fix portability bugs in use of credentials control messages for peer auth. Even though our existing code for handling credentials control messages has been basically unchanged since 2001, it was fundamentally wrong: it did not ensure proper alignment of the supplied buffer, and it was calculating buffer sizes and message sizes incorrectly. This led to failures on platforms where alignment padding is relevant, for instance FreeBSD on 64-bit platforms, as seen in a recent Debian bug report passed on by Martin Pitt (http://bugs.debian.org//cgi-bin/bugreport.cgi?bug=612888). Rewrite to do the message-whacking using the macros specified in RFC 2292, following a suggestion from Theo de Raadt in that thread. Tested by me on Debian/kFreeBSD-amd64; since OpenBSD and NetBSD document the identical CMSG API, it should work there too. Back-patch to all supported branches. 30 May 2011, 23:16:28 UTC
6d24189 Tom Lane 26 May 2011, 23:25:19 UTC Make decompilation of optimized CASE constructs more robust. We had some hacks in ruleutils.c to cope with various odd transformations that the optimizer could do on a CASE foo WHEN "CaseTestExpr = RHS" clause. However, the fundamental impossibility of covering all cases was exposed by Heikki, who pointed out that the "=" operator could get replaced by an inlined SQL function, which could contain nearly anything at all. So give up on the hacks and just print the expression as-is if we fail to recognize it as "CaseTestExpr = RHS". (We must cover that case so that decompiled rules print correctly; but we are not under any obligation to make EXPLAIN output be 100% valid SQL in all cases, and already could not do so in some other cases.) This approach requires that we have some printable representation of the CaseTestExpr node type; I used "CASE_TEST_EXPR". Back-patch to all supported branches, since the problem case fails in all. 26 May 2011, 23:26:12 UTC
ea393e4 Tom Lane 23 May 2011, 16:53:05 UTC Install defenses against overflow in BuildTupleHashTable(). The planner can sometimes compute very large values for numGroups, and in cases where we have no alternative to building a hashtable, such a value will get fed directly to BuildTupleHashTable as its nbuckets parameter. There were two ways in which that could go bad. First, BuildTupleHashTable declared the parameter as "int" but most callers were passing "long"s, so on 64-bit machines undetected overflow could occur leading to a bogus negative value. The obvious fix for that is to change the parameter to "long", which is what I've done in HEAD. In the back branches that seems a bit risky, though, since third-party code might be calling this function. So for them, just put in a kluge to treat negative inputs as INT_MAX. Second, hash_create can go nuts with extremely large requested table sizes (notably, my_log2 becomes an infinite loop for inputs larger than LONG_MAX/2). What seems most appropriate to avoid that is to bound the initial table size request to work_mem. This fixes bug #6035 reported by Daniel Schreiber. Although the reported case only occurs back to 8.4 since it involves WITH RECURSIVE, I think it's a good idea to install the defenses in all supported branches. 23 May 2011, 16:53:05 UTC
1f57a2f Heikki Linnakangas 19 May 2011, 02:30:24 UTC Replace strdup() with pstrdup(), to avoid leaking memory. It's been like this since the seg module was introduced, so backpatch to 8.2 which is the oldest supported version. 19 May 2011, 02:36:37 UTC
a7d3110 Tom Lane 12 May 2011, 15:56:38 UTC Fix write-past-buffer-end in ldapServiceLookup(). The code to assemble ldap_get_values_len's output into a single string wrote the terminating null one byte past where it should. Fix that, and make some other cosmetic adjustments to make the code a trifle more readable and more in line with usual Postgres coding style. Also, free the "result" string when done with it, to avoid a permanent memory leak. Bug report and patch by Albe Laurenz, cosmetic adjustments by me. 12 May 2011, 15:57:26 UTC
7b9bbb6 Peter Eisentraut 01 May 2011, 21:54:02 UTC Catch errors in for loop in makefile Add "|| exit" so that the rule aborts when a command fails. This is the minimal backpatch version. The fix in head is more elaborate. 01 May 2011, 21:54:02 UTC
9b51d50 Tom Lane 29 April 2011, 05:45:27 UTC Rewrite pg_size_pretty() to avoid compiler bug. Convert it to use successive shifts right instead of increasing a divisor. This is probably a tad more efficient than the original coding, and it's nicer-looking than the previous patch because we don't need a special case to avoid overflow in the last branch. But the real reason to do it is to avoid a Solaris compiler bug, as per results from buildfarm member moa. 29 April 2011, 05:45:27 UTC
1aa24e2 Heikki Linnakangas 28 April 2011, 09:51:02 UTC The arguments to pg_ctl kill are not optional - remove brackets in the docs. Fujii Masao 28 April 2011, 09:57:14 UTC
ed84942 Tom Lane 27 April 2011, 17:58:59 UTC Fix array- and path-creating functions to ensure padding bytes are zeroes. Per recent discussion, it's important for all computed datums (not only the results of input functions) to not contain any ill-defined (uninitialized) bits. Failing to ensure that can result in equal() reporting that semantically indistinguishable Consts are not equal, which in turn leads to bizarre and undesirable planner behavior, such as in a recent example from David Johnston. We might eventually try to fix this in a general manner by allowing datatypes to define identity-testing functions, but for now the path of least resistance is to expect datatypes to force all unused bits into consistent states. Per some testing by Noah Misch, array and path functions seem to be the only ones presenting risks at the moment, so I looked through all the functions in adt/array*.c and geo_ops.c and fixed them as necessary. In the array functions, the easiest/safest fix is to allocate result arrays with palloc0 instead of palloc. Possibly in future someone will want to look into whether we can just zero the padding bytes, but that looks too complex for a back-patchable fix. In the path functions, we already had a precedent in path_in for just zeroing the one known pad field, so duplicate that code as needed. Back-patch to all supported branches. 27 April 2011, 17:58:59 UTC
d3964cd Tom Lane 25 April 2011, 20:22:28 UTC Fix pg_size_pretty() to avoid overflow for inputs close to INT64_MAX. The expression that tried to round the value to the nearest TB could overflow, leading to bogus output as reported in bug #5993 from Nicola Cossu. This isn't likely to ever happen in the intended usage of the function (if it could, we'd be needing to use a wider datatype instead); but it's not hard to give the expected output, so let's do so. 25 April 2011, 20:22:28 UTC
1e28982 Marc G. Fournier 15 April 2011, 03:19:01 UTC Tag 8.2.21. 15 April 2011, 03:19:01 UTC
3c97915 Peter Eisentraut 14 April 2011, 19:29:44 UTC Translation updates 14 April 2011, 20:30:54 UTC
3d2835e Tom Lane 14 April 2011, 19:51:55 UTC Update release notes for releases 9.0.4, 8.4.8, 8.3.15, and 8.2.21. 14 April 2011, 19:51:55 UTC
1865975 Tom Lane 13 April 2011, 22:03:23 UTC Update time zone data files to tzdata release 2011f. DST law changes in Chile, Cuba, Falkland Islands, Morocco, Samoa, Turkey. Historical corrections for South Australia, Alaska, Hawaii. 13 April 2011, 22:05:23 UTC
4f5ed3a Heikki Linnakangas 13 April 2011, 08:43:22 UTC On IA64 architecture, we check the depth of the register stack in addition to the regular stack. The code to do that is platform and compiler specific, add support for the HP-UX native compiler. 13 April 2011, 08:53:30 UTC
1de4b9a Tom Lane 07 April 2011, 19:15:00 UTC Modernize dlopen interface code for FreeBSD and OpenBSD. Remove the hard-wired assumption that __mips__ (and only __mips__) lacks dlopen in FreeBSD and OpenBSD. This assumption is outdated at least for OpenBSD, as per report from an anonymous 9.1 tester. We can perfectly well use HAVE_DLOPEN instead to decide which code to use. Some other cosmetic adjustments to make freebsd.c, netbsd.c, and openbsd.c exactly alike. 07 April 2011, 19:15:00 UTC
00a9229 Tom Lane 07 April 2011, 15:40:44 UTC Fix SortTocFromFile() to cope with lines that are too long for its buffer. The original coding supposed that a dump TOC file could never contain lines longer than 1K. The folly of that was exposed by a recent report from Per-Olov Esgard. We only really need to see the first dozen or two bytes of each line, since we're just trying to read off the numeric ID at the start of the line; so there's no need for a particularly huge buffer. What there is a need for is logic to not process continuation bufferloads. Back-patch to all supported branches, since it's always been like this. 07 April 2011, 15:40:44 UTC
93acf04 Robert Haas 28 March 2011, 01:28:15 UTC Correct "characters" to "bytes" in createdb docs. Susanne Ebrecht 28 March 2011, 01:29:32 UTC
63fe94d Tom Lane 23 March 2011, 20:57:41 UTC Improve user-defined-aggregates documentation. On closer inspection, that two-element initcond value seems to have been a little white lie to avoid explaining the full behavior of float8_accum. But if people are going to expect the examples to be exactly correct, I suppose we'd better explain. Per comment from Thom Brown. 23 March 2011, 20:57:41 UTC
24cdee8 Tom Lane 23 March 2011, 16:33:14 UTC Fix ancient typo in user-defined-aggregates documentation. The description of the initcond value for the built-in avg(float8) aggregate has been wrong since it was written. Noted by Disc Magnet. 23 March 2011, 16:34:16 UTC
e2d64f8 Tom Lane 22 March 2011, 17:01:23 UTC Avoid potential deadlock in InitCatCachePhase2(). Opening a catcache's index could require reading from that cache's own catalog, which of course would acquire AccessShareLock on the catalog. So the original coding here risks locking index before heap, which could deadlock against another backend trying to get exclusive locks in the normal order. Because InitCatCachePhase2 is only called when a backend has to start up without a relcache init file, the deadlock was seldom seen in the field. (And by the same token, there's no need to worry about any performance disadvantage; so not much point in trying to distinguish exactly which catalogs have the risk.) Bug report, diagnosis, and patch by Nikhil Sontakke. Additional commentary by me. Back-patch to all supported branches. 22 March 2011, 17:01:23 UTC
151e463 Alvaro Herrera 17 March 2011, 15:49:38 UTC Fix PL/Python memory leak involving array slices Report and patch from Daniel Popowich, bug #5842 (with some debugging help from Alex Hunsaker) 17 March 2011, 15:50:38 UTC
5773fac Andrew Dunstan 17 March 2011, 04:24:04 UTC Use correct PATH separator for Cygwin in pg_regress.c. This has been broken for years, and I'm not sure why it has not been noticed before, but now a very modern Cygwin breaks on it, and the fix is clearly correct. Backpatching to all live branches. 17 March 2011, 04:24:04 UTC
1b5a777 Tom Lane 12 March 2011, 00:04:18 UTC On further reflection, we'd better do the same in int.c. We previously heard of the same problem in int24div(), so there's not a good reason to suppose the problem is confined to cases involving int8. 12 March 2011, 00:04:18 UTC
a396d88 Tom Lane 11 March 2011, 23:19:11 UTC Put in some more safeguards against executing a division-by-zero. Add dummy returns before every potential division-by-zero in int8.c, because apparently further "improvements" in gcc's optimizer have enabled it to break functions that weren't broken before. Aurelien Jarno, via Martin Pitt 11 March 2011, 23:19:11 UTC
1487ca0 Tom Lane 22 February 2011, 02:18:30 UTC Fix dangling-pointer problem in before-row update trigger processing. ExecUpdate checked for whether ExecBRUpdateTriggers had returned a new tuple value by seeing if the returned tuple was pointer-equal to the old one. But the "old one" was in estate->es_junkFilter's result slot, which would be scribbled on if we had done an EvalPlanQual update in response to a concurrent update of the target tuple; therefore we were comparing a dangling pointer to a live one. Given the right set of circumstances we could get a false match, resulting in not forcing the tuple to be stored in the slot we thought it was stored in. In the case reported by Maxim Boguk in bug #5798, this led to "cannot extract system attribute from virtual tuple" failures when trying to do "RETURNING ctid". I believe there is a very-low-probability chance of more serious errors, such as generating incorrect index entries based on the original rather than the trigger-modified version of the row. In HEAD, change all of ExecBRInsertTriggers, ExecIRInsertTriggers, ExecBRUpdateTriggers, and ExecIRUpdateTriggers so that they continue to have similar APIs. In the back branches I just changed ExecBRUpdateTriggers, since there is no bug in the ExecBRInsertTriggers case. 22 February 2011, 02:18:30 UTC
69bef7f Tom Lane 15 February 2011, 20:50:17 UTC Add CheckTableNotInUse calls in DROP TABLE and DROP INDEX. Recent releases had a check on rel->rd_refcnt in heap_drop_with_catalog, but failed to cover the possibility of pending trigger events at DROP time. (Before 8.4 we didn't even check the refcnt.) When the trigger events were eventually fired, you'd get "could not open relation with OID nnn" errors, as in recent report from strk. Better to throw a suitable error when the DROP is attempted. Also add a similar check in DROP INDEX. Back-patch to all supported branches. 15 February 2011, 20:50:17 UTC
13a9a7b Itagaki Takahiro 01 February 2011, 06:48:08 UTC Fix wrong error reports in 'number of array dimensions exceeds the maximum allowed' messages, that have reported one-less dimensions. Alexey Klyukin 01 February 2011, 06:48:42 UTC
f62f223 Marc G. Fournier 28 January 2011, 02:25:42 UTC Tag 8.2.20 28 January 2011, 02:25:42 UTC
f6ba576 Tom Lane 27 January 2011, 22:45:55 UTC Update release notes. Security: CVE-2010-4015 27 January 2011, 22:47:32 UTC
e11349f Tom Lane 27 January 2011, 22:42:00 UTC Prevent buffer overrun while parsing an integer in a "query_int" value. contrib/intarray's gettoken() uses a fixed-size buffer to collect an integer's digits, and did not guard against overrunning the buffer. This is at least a backend crash risk, and in principle might allow arbitrary code execution. The code didn't check for overflow of the integer value either, which while not presenting a crash risk was still bad. Thanks to Apple Inc's security team for reporting this issue and supplying the fix. Security: CVE-2010-4015 27 January 2011, 22:43:45 UTC
948a64d Tom Lane 27 January 2011, 21:27:27 UTC Don't include <asm/ia64regs.h> unnecessarily. We only need that header when compiling with icc, since the gcc variant of ia64_get_bsp() uses in-line assembly code. Per report from Frank Brendel, the header doesn't exist on all IA64 platforms; so don't include it unless we need it. 27 January 2011, 21:30:03 UTC
d5a0bb5 Peter Eisentraut 27 January 2011, 19:15:18 UTC Translation updates for release 8.2.20 27 January 2011, 21:13:00 UTC
85dfc48 Tom Lane 27 January 2011, 21:10:15 UTC Update release notes for releases 9.0.3, 8.4.7, 8.3.14, and 8.2.20. 27 January 2011, 21:10:15 UTC
aae2a02 Tom Lane 21 January 2011, 21:22:35 UTC Fix pg_restore to do the right thing when escaping large objects. Specifically, this makes the workflow pg_dump -Fc -> pg_restore -> file produce correct output for BLOBs when the source database has standard_conforming_strings turned on. It was already okay when that was off, or if pg_restore was told to restore directly into a database. This is a back-port of commit b1732111f233bbb72788e92a627242ec28a85631 of 2009-08-04, with additional changes to emit old-style escaped bytea data instead of hex-style. At the time, we had not heard of anyone encountering the problem in the field, so I judged it not worth the risk of changing back branches. Now we do have a report, from Bosco Rama, so back-patch into 8.2 through 8.4. 9.0 and up are okay already. 21 January 2011, 21:22:35 UTC
2a0abe1 Tom Lane 17 January 2011, 17:38:52 UTC Fix miscalculation of itemsafter in array_set_slice(). If the slice to be assigned to was before the existing array lower bound (requiring at least one null element to spring into existence to fill the gap), the code miscalculated how many entries needed to be copied from the old array's null bitmap. This could result in trashing the array's data area (as seen in bug #5840 from Karsten Loesing), or worse. This has been broken since we first allowed the behavior of assigning to non-adjacent slices, in 8.2. Back-patch to all affected versions. 17 January 2011, 17:41:01 UTC
ebbf741 Andrew Dunstan 04 January 2011, 21:07:05 UTC Allow older branches to be built with Visual Studio 2008. This is a backport of commit df0cdd53 to the 8.2, 8.3 and 8.4 branches. 04 January 2011, 21:07:05 UTC
back to top