Skip to main content

Browse the archive

https://github.com/postgres/postgres
02 May 2024, 11:03:54 UTC
sort by:
Revision Author Date Message Commit Date
0caf562 Tom Lane 04 February 2013, 21:26:39 UTC Stamp 8.3.23. 04 February 2013, 21:29:07 UTC
aa27464 Tom Lane 04 February 2013, 21:25:30 UTC Prevent execution of enum_recv() from SQL. This function was misdeclared to take cstring when it should take internal. This at least allows crashing the server, and in principle an attacker might be able to use the function to examine the contents of server memory. The correct fix is to adjust the system catalog contents (and fix the regression tests that should have caught this but failed to). However, asking users to correct the catalog contents in existing installations is a pain, so as a band-aid fix for the back branches, install a check in enum_recv() to make it throw error if called with a cstring argument. We will later revert this in HEAD in favor of correcting the catalogs. Our thanks to Sumit Soni (via Secunia SVCRP) for reporting this issue. Security: CVE-2013-0255 04 February 2013, 21:25:30 UTC
fea6323 Tom Lane 04 February 2013, 20:51:00 UTC Update release notes for 9.2.3, 9.1.8, 9.0.12, 8.4.16, 8.3.23. 04 February 2013, 20:51:00 UTC
eb6cbbe Peter Eisentraut 04 February 2013, 04:50:30 UTC Translation updates 04 February 2013, 04:50:30 UTC
186a0c9 Magnus Hagander 31 January 2013, 14:08:05 UTC Properly zero-pad the day-of-year part of the win32 build number This ensure the version number increases over time. The first three digits in the version number is still set to the actual PostgreSQL version number, but the last one is intended to be an ever increasing build number, which previosly failed when it changed between 1, 2 and 3 digits long values. Noted by Deepak 31 January 2013, 14:09:25 UTC
66e6916 Tom Lane 30 January 2013, 19:16:59 UTC Fix grammar for subscripting or field selection from a sub-SELECT result. Such cases should work, but the grammar failed to accept them because of our ancient precedence hacks to convince bison that extra parentheses around a sub-SELECT in an expression are unambiguous. (Formally, they *are* ambiguous, but we don't especially care whether they're treated as part of the sub-SELECT or part of the expression. Bison cares, though.) Fix by adding a redundant-looking production for this case. This is a fine example of why fixing shift/reduce conflicts via precedence declarations is more dangerous than it looks: you can easily cause the parser to reject cases that should work. This has been wrong since commit 3db4056e22b0c6b2adc92543baf8408d2894fe91 or maybe before, and apparently some people have been working around it by inserting no-op casts. That method introduces a dump/reload hazard, as illustrated in bug #7838 from Jan Mate. Hence, back-patch to all active branches. 30 January 2013, 19:16:59 UTC
85abf1d Alvaro Herrera 28 January 2013, 20:46:47 UTC DROP OWNED: don't try to drop tablespaces/databases My "fix" for bugs #7578 and #6116 on DROP OWNED at fe3b5eb08a1 not only misstated that it applied to REASSIGN OWNED (which it did not affect), but it also failed to fix the problems fully, because I didn't test the case of owned shared objects. Thus I created a new bug, reported by Thomas Kellerer as #7748, which would cause DROP OWNED to fail with a not-for-user-consumption error message. The code would attempt to drop the database, which not only fails to work because the underlying code does not support that, but is a pretty dangerous and undesirable thing to be doing as well. This patch fixes that bug by having DROP OWNED only attempt to process shared objects when grants on them are found, ignoring ownership. Backpatch to 8.3, which is as far as the previous bug was backpatched. 28 January 2013, 22:13:06 UTC
de51042 Andrew Dunstan 24 January 2013, 21:01:31 UTC Use correct output device for Windows prompts. This ensures that mapping of non-ascii prompts to the correct code page occurs. Bug report and original patch from Alexander Law, reviewed and reworked by Noah Misch. Backpatch to all live branches. 24 January 2013, 21:01:31 UTC
59d70a5 Tom Lane 21 January 2013, 04:44:11 UTC Fix one-byte buffer overrun in PQprintTuples(). This bug goes back to the original Postgres95 sources. Its significance to modern PG versions is marginal, since we have not used PQprintTuples() internally in a very long time, and it doesn't seem to have ever been documented either. Still, it *is* exposed to client apps, so somebody out there might possibly be using it. Xi Wang 21 January 2013, 04:44:11 UTC
237dc2d Andrew Dunstan 19 January 2013, 19:54:29 UTC Make pgxs build executables with the right suffix. Complaint and patch from Zoltán Böszörményi. When cross-compiling, the native make doesn't know about the Windows .exe suffix, so it only builds with it when explicitly told to do so. The native make will not see the link between the target name and the built executable, and might this do unnecesary work, but that's a bigger problem than this one, if in fact we consider it a problem at all. Back-patch to all live branches. 19 January 2013, 19:54:29 UTC
6eedec1 Tom Lane 18 January 2013, 23:06:50 UTC Protect against SnapshotNow race conditions in pg_tablespace scans. Use of SnapshotNow is known to expose us to race conditions if the tuple(s) being sought could be updated by concurrently-committing transactions. CREATE DATABASE and DROP DATABASE are particularly exposed because they do heavyweight filesystem operations during their scans of pg_tablespace, so that the scans run for a very long time compared to most. Furthermore, the potential consequences of a missed or twice-visited row are nastier than average: * createdb() could fail with a bogus "file already exists" error, or silently fail to copy one or more tablespace's worth of files into the new database. * remove_dbtablespaces() could miss one or more tablespaces, thus failing to free filesystem space for the dropped database. * check_db_file_conflict() could likewise miss a tablespace, leading to an OID conflict that could result in data loss either immediately or in future operations. (This seems of very low probability, though, since a duplicate database OID would be unlikely to start with.) Hence, it seems worth fixing these three places to use MVCC snapshots, even though this will someday be superseded by a generic solution to SnapshotNow race conditions. Back-patch to all active branches. Stephen Frost and Tom Lane 18 January 2013, 23:06:50 UTC
46dc33f Heikki Linnakangas 15 January 2013, 20:09:41 UTC On second thought, use an empty string instead of "none" when not connected. "none" could mislead to think that you're connected a database with that name. Also, it needs to be translated, which might be hard without some context. So in back-branches, use empty string, so that the message is (currently ""), which is at least unambiguous and doens't require translation. In master, it's no problem to add translatable strings, so use a different fix there. 15 January 2013, 20:14:25 UTC
63b0b39 Heikki Linnakangas 15 January 2013, 16:54:03 UTC Don't pass NULL to fprintf, if not currently connected to a database. Backpatch all the way to 8.3. Fixes bug #7811, per report and diagnosis by Meng Qingzhong. 15 January 2013, 17:20:42 UTC
0af83bd Tom Lane 14 January 2013, 19:45:40 UTC Add new timezone abbrevation "FET". This seems to have been invented in 2011 to represent GMT+3, non daylight savings rules, as now used in Europe/Kaliningrad and Europe/Minsk. There are no conflicts so might as well add it to the Default list. Per bug #7804 from Ruslan Izmaylov. 14 January 2013, 19:47:34 UTC
7178129 Bruce Momjian 01 January 2013, 22:14:59 UTC Update copyrights for 2013 Fully update git head, and update back branches in ./COPYRIGHT and legal.sgml files. 01 January 2013, 22:14:59 UTC
4297f17 Tom Lane 23 December 2012, 19:07:52 UTC Prevent failure when RowExpr or XmlExpr is parse-analyzed twice. transformExpr() is required to cope with already-transformed expression trees, for various ugly-but-not-quite-worth-cleaning-up reasons. However, some of its newer subroutines hadn't gotten the memo. This accounts for bug #7763 from Norbert Buchmuller: transformRowExpr() was overwriting the previously determined type of a RowExpr during CREATE TABLE LIKE INCLUDING INDEXES. Additional investigation showed that transformXmlExpr had the same kind of problem, but all the other cases seem to be safe. Andres Freund and Tom Lane 23 December 2012, 19:07:52 UTC
3fd0393 Tom Lane 18 December 2012, 21:22:43 UTC Ignore libedit/libreadline while probing for standard functions. Some versions of libedit expose bogus definitions of setproctitle(), optreset, and perhaps other symbols that we don't want configure to pick up on. There was a previous report of similar problems with strlcpy(), which we addressed in commit 59cf88da91bc88978b05275ebd94ac2d980c4047, but the problem has evidently grown in scope since then. In hopes of not having to deal with it again in future, rearrange configure's tests for supplied functions so that we ignore libedit/libreadline except when probing specifically for functions we expect them to provide. Per report from Christoph Berg, though this is slightly more aggressive than his proposed patch. 18 December 2012, 21:22:43 UTC
b7ef58a Tom Lane 12 December 2012, 03:09:39 UTC Add defenses against integer overflow in dynahash numbuckets calculations. The dynahash code requires the number of buckets in a hash table to fit in an int; but since we calculate the desired hash table size dynamically, there are various scenarios where we might calculate too large a value. The resulting overflow can lead to infinite loops, division-by-zero crashes, etc. I (tgl) had previously installed some defenses against that in commit 299d1716525c659f0e02840e31fbe4dea3, but that covered only one call path. Moreover it worked by limiting the request size to work_mem, but in a 64-bit machine it's possible to set work_mem high enough that the problem appears anyway. So let's fix the problem at the root by installing limits in the dynahash.c functions themselves. Trouble report and patch by Jeff Davis. 12 December 2012, 03:09:39 UTC
175f7a3 Peter Eisentraut 08 December 2012, 12:36:25 UTC Update ISO 3166 link The old one no longer pointed to anything useful. 08 December 2012, 12:43:42 UTC
632e7b6 Tom Lane 03 December 2012, 20:28:41 UTC Stamp 8.3.22. 03 December 2012, 20:28:41 UTC
50fe9a6 Tom Lane 03 December 2012, 20:10:27 UTC Update release notes for 9.2.2, 9.1.7, 9.0.11, 8.4.15, 8.3.22. 03 December 2012, 20:10:27 UTC
1f46d67 Tom Lane 03 December 2012, 16:09:16 UTC Fix documentation of path(polygon) function. Obviously, this returns type "path", but somebody made a copy-and-pasteo long ago. Dagfinn Ilmari Mannsåker 03 December 2012, 16:09:16 UTC
42a7bea Peter Eisentraut 03 December 2012, 12:50:43 UTC Translation updates 03 December 2012, 12:50:43 UTC
628a0c7 Tom Lane 02 December 2012, 21:35:23 UTC Update time zone data files to tzdata release 2012j. DST law changes in Cuba, Israel, Jordan, Libya, Palestine, Western Samoa, and portions of Brazil. 02 December 2012, 21:37:07 UTC
eb851c9 Tatsuo Ishii 02 December 2012, 12:11:15 UTC Fix psql crash while parsing SQL file whose encoding is different from client encoding and the client encoding is not *safe* one. Such an example is, file encoding is UTF-8 and client encoding SJIS. Patch contributed by Jiang Guiqing. 02 December 2012, 12:23:51 UTC
9009ec0 Tom Lane 01 December 2012, 22:24:15 UTC Prevent passing gmake's environment variables down through pg_regress. When we do "make install" to create a temp installation, we don't want that instance of make to try to communicate with any instance of make that might be calling us. This is known to cause problems if the upper make has a -jN flag, and in principle could cause problems even without that. Unset the relevant environment variables to prevent such issues. Andres Freund 01 December 2012, 22:24:15 UTC
b10b1fa Tom Lane 30 November 2012, 22:02:53 UTC Take buffer lock while inspecting btree index pages in contrib/pageinspect. It's not safe to examine a shared buffer without any lock. 30 November 2012, 22:02:53 UTC
244413f Tom Lane 30 November 2012, 18:56:24 UTC Add missing buffer lock acquisition in GetTupleForTrigger(). If we had not been holding buffer pin continuously since the tuple was initially fetched by the UPDATE or DELETE query, it would be possible for VACUUM or a page-prune operation to move the tuple while we're trying to copy it. This would result in a garbage "old" tuple value being passed to an AFTER ROW UPDATE or AFTER ROW DELETE trigger. The preconditions for this are somewhat improbable, and the timing constraints are very tight; so it's not so surprising that this hasn't been reported from the field, even though the bug has been there a long time. Problem found by Andres Freund. Back-patch to all active branches. 30 November 2012, 18:56:24 UTC
9837be9 Tom Lane 30 November 2012, 00:57:38 UTC Produce a more useful error message for over-length Unix socket paths. The length of a socket path name is constrained by the size of struct sockaddr_un, and there's not a lot we can do about it since that is a kernel API. However, it would be a good thing if we produced an intelligible error message when the user specifies a socket path that's too long --- and getaddrinfo's standard API is too impoverished to do this in the natural way. So insert explicit tests at the places where we construct a socket path name. Now you'll get an error that makes sense and even tells you what the limit is, rather than something generic like "Non-recoverable failure in name resolution". Per trouble report from Jeremy Drake and a fix idea from Andrew Dunstan. 30 November 2012, 00:57:38 UTC
5c8c7c7 Tom Lane 29 November 2012, 19:50:53 UTC Fix assorted bugs in CREATE INDEX CONCURRENTLY. This patch changes CREATE INDEX CONCURRENTLY so that the pg_index flag changes it makes without exclusive lock on the index are made via heap_inplace_update() rather than a normal transactional update. The latter is not very safe because moving the pg_index tuple could result in concurrent SnapshotNow scans finding it twice or not at all, thus possibly resulting in index corruption. In addition, fix various places in the code that ought to check to make sure that the indexes they are manipulating are valid and/or ready as appropriate. These represent bugs that have existed since 8.2, since a failed CREATE INDEX CONCURRENTLY could leave a corrupt or invalid index behind, and we ought not try to do anything that might fail with such an index. Also fix RelationReloadIndexInfo to ensure it copies all the pg_index columns that are allowed to change after initial creation. Previously we could have been left with stale values of some fields in an index relcache entry. It's not clear whether this actually had any user-visible consequences, but it's at least a bug waiting to happen. This is a subset of a patch already applied in 9.2 and HEAD. Back-patch into all earlier supported branches. Tom Lane and Andres Freund 29 November 2012, 19:52:37 UTC
fc9b2d0 Michael Meskes 29 November 2012, 16:12:00 UTC When processing nested structure pointer variables ecpg always expected an array datatype which of course is wrong. Applied patch by Muhammad Usama <m.usama@gmail.com> to fix this. 29 November 2012, 16:16:17 UTC
8b81217 Bruce Momjian 26 November 2012, 22:36:21 UTC Remove inaccurate "Incrementally Updated Backups" documentation section; already removed from 9.0+. Applied to 8.3 and 8.4. 26 November 2012, 22:36:21 UTC
336bc0d Tom Lane 22 November 2012, 16:23:46 UTC Fix pg_resetxlog to use correct path to postmaster.pid. Since we've already chdir'd into the data directory, the file should be referenced as just "postmaster.pid", without prefixing the directory path. This is harmless in the normal case where an absolute PGDATA path is used, but quite dangerous if a relative path is specified, since the program might then fail to notice an active postmaster. Reported by Hari Babu. This got broken in my commit eb5949d190e80360386113fde0f05854f0c9824d, so patch all active versions. 22 November 2012, 16:23:46 UTC
3352e25 Tom Lane 20 November 2012, 02:22:00 UTC Improve handling of INT_MIN / -1 and related cases. Some platforms throw an exception for this division, rather than returning a necessarily-overflowed result. Since we were testing for overflow after the fact, an exception isn't nice. We can avoid the problem by treating division by -1 as negation. Add some regression tests so that we'll find out if any compilers try to optimize away the overflow check conditions. Back-patch of commit 1f7cb5c30983752ff8de833de30afcaee63536d0. Per discussion with Xi Wang, though this is different from the patch he submitted. 20 November 2012, 02:22:00 UTC
8728fdc Tom Lane 18 November 2012, 22:15:32 UTC Limit values of archive_timeout, post_auth_delay, auth_delay.milliseconds. The previous definitions of these GUC variables allowed them to range up to INT_MAX, but in point of fact the underlying code would suffer overflows or other errors with large values. Reduce the maximum values to something that won't misbehave. There's no apparent value in working harder than this, since very large delays aren't sensible for any of these. (Note: the risk with archive_timeout is that if we're late checking the state, the timestamp difference it's being compared to might overflow. So we need some amount of slop; the choice of INT_MAX/2 is arbitrary.) Per followup investigation of bug #7670. Although this isn't a very significant fix, might as well back-patch. 18 November 2012, 22:15:32 UTC
46c79df Tom Lane 14 November 2012, 22:30:18 UTC Fix the int8 and int2 cases of (minimum possible integer) % (-1). The correct answer for this (or any other case with arg2 = -1) is zero, but some machines throw a floating-point exception instead of behaving sanely. Commit f9ac414c35ea084ff70c564ab2c32adb06d5296f dealt with this in int4mod, but overlooked the fact that it also happens in int8mod (at least on my Linux x86_64 machine). Protect int2mod as well; it's not clear whether any machines fail there (mine does not) but since the test is so cheap it seems better safe than sorry. While at it, simplify the original guard in int4mod: we need only check for arg2 == -1, we don't need to check arg1 explicitly. Xi Wang, with some editing by me. 14 November 2012, 22:30:18 UTC
c027d84 Tom Lane 13 November 2012, 19:44:56 UTC Fix memory leaks in record_out() and record_send(). record_out() leaks memory: it fails to free the strings returned by the per-column output functions, and also is careless about detoasted values. This results in a query-lifespan memory leakage when returning composite values to the client, because printtup() runs the output functions in the query-lifespan memory context. Fix it to handle these issues the same way printtup() does. Also fix a similar leakage in record_send(). (At some point we might want to try to run output functions in shorter-lived memory contexts, so that we don't need a zero-leakage policy for them. But that would be a significantly more invasive patch, which doesn't seem like material for back-patching.) In passing, use appendStringInfoCharMacro instead of appendStringInfoChar in the innermost data-copying loop of record_out, to try to shave a few cycles from this function's runtime. Per trouble report from Carlos Henrique Reimer. Back-patch to all supported versions. 13 November 2012, 19:44:56 UTC
2faab1a Tom Lane 12 November 2012, 00:56:36 UTC Check for stack overflow in transformSetOperationTree(). Since transformSetOperationTree() recurses, it can be driven to stack overflow with enough UNION/INTERSECT/EXCEPT clauses in a query. Add a check to ensure it fails cleanly instead of crashing. Per report from Matthew Gerber (though it's not clear whether this is the only thing going wrong for him). Historical note: I think the reasoning behind not putting a check here in the beginning was that the check in transformExpr() ought to be sufficient to guard the whole parser. However, because transformSetOperationTree() recurses all the way to the bottom of the set-operation tree before doing any analysis of the statement's expressions, that check doesn't save it. 12 November 2012, 00:56:36 UTC
29d539b Tom Lane 26 October 2012, 18:20:15 UTC Prefer actual constants to pseudo-constants in equivalence class machinery. generate_base_implied_equalities_const() should prefer plain Consts over other em_is_const eclass members when choosing the "pivot" value that all the other members will be equated to. This makes it more likely that the generated equalities will be useful in constraint-exclusion proofs. Per report from Rushabh Lathia. 26 October 2012, 18:20:15 UTC
2383d6d Tom Lane 24 October 2012, 18:54:17 UTC Prevent parser from believing that views have system columns. Views should not have any pg_attribute entries for system columns. However, we forgot to remove such entries when converting a table to a view. This could lead to crashes later on, if someone attempted to reference such a column, as reported by Kohei KaiGai. This problem is corrected properly in HEAD (by removing the pg_attribute entries during conversion), but in the back branches we need to defend against existing mis-converted views. This fix costs us an extra syscache lookup per system column reference, which is annoying but probably not really measurable in the big scheme of things. 24 October 2012, 18:54:17 UTC
613a9ed Tom Lane 19 October 2012, 19:24:32 UTC Fix hash_search to avoid corruption of the hash table on out-of-memory. An out-of-memory error during expand_table() on a palloc-based hash table would leave a partially-initialized entry in the table. This would not be harmful for transient hash tables, since they'd get thrown away anyway at transaction abort. But for long-lived hash tables, such as the relcache hash, this would effectively corrupt the table, leading to crash or other misbehavior later. To fix, rearrange the order of operations so that table enlargement is attempted before we insert a new entry, rather than after adding it to the hash table. Problem discovered by Hitoshi Harada, though this is a bit different from his proposed patch. 19 October 2012, 19:24:32 UTC
16eb7c7 Tom Lane 19 October 2012, 17:40:34 UTC Fix ruleutils to print "INSERT INTO foo DEFAULT VALUES" correctly. Per bug #7615 from Marko Tiikkaja. Apparently nobody ever tried this case before ... 19 October 2012, 17:40:34 UTC
8658c09 Heikki Linnakangas 18 October 2012, 19:26:26 UTC Further tweaking of the readfile() function in pg_ctl. Don't leak a file descriptor if the file is empty or we can't read its size. Expect there to be a newline at the end of the last line, too. If there isn't, ignore anything after the last newline. This makes it a tiny bit more robust in case the file is appended to concurrently, so that we don't return the last line if it hasn't been fully written yet. And this makes the code a bit less obscure, anyway. Per Tom Lane's suggestion. Backpatch to all supported branches. 18 October 2012, 19:30:55 UTC
c29a910 Tom Lane 18 October 2012, 16:29:19 UTC Fix planning of non-strict equivalence clauses above outer joins. If a potential equivalence clause references a variable from the nullable side of an outer join, the planner needs to take care that derived clauses are not pushed to below the outer join; else they may use the wrong value for the variable. (The problem arises only with non-strict clauses, since if an upper clause can be proven strict then the outer join will get simplified to a plain join.) The planner attempted to prevent this type of error by checking that potential equivalence clauses aren't outerjoin-delayed as a whole, but actually we have to check each side separately, since the two sides of the clause will get moved around separately if it's treated as an equivalence. Bugs of this type can be demonstrated as far back as 7.4, even though releases before 8.3 had only a very ad-hoc notion of equivalence clauses. In addition, we neglected to account for the possibility that such clauses might have nonempty nullable_relids even when not outerjoin-delayed; so the equivalence-class machinery lacked logic to compute correct nullable_relids values for clauses it constructs. This oversight was harmless before 9.2 because we were only using RestrictInfo.nullable_relids for OR clauses; but as of 9.2 it could result in pushing constructed equivalence clauses to incorrect places. (This accounts for bug #7604 from Bill MacArthur.) Fix the first problem by adding a new test check_equivalence_delay() in distribute_qual_to_rels, and fix the second one by adding code in equivclass.c and called functions to set correct nullable_relids for generated clauses. Although I believe the second part of this is not currently necessary before 9.2, I chose to back-patch it anyway, partly to keep the logic similar across branches and partly because it seems possible we might find other reasons why we need valid values of nullable_relids in the older branches. Add regression tests illustrating these problems. In 9.0 and up, also add test cases checking that we can push constants through outer joins, since we've broken that optimization before and I nearly broke it again with an overly simplistic patch for this problem. 18 October 2012, 16:29:19 UTC
7bdaacf Simon Riggs 17 October 2012, 08:25:00 UTC Fix typo in previous commit 17 October 2012, 08:25:00 UTC
6166c73 Simon Riggs 17 October 2012, 07:36:45 UTC Add hash index caution to CREATE INDEX docs 17 October 2012, 07:36:45 UTC
17901b0 Heikki Linnakangas 13 October 2012, 09:48:14 UTC Fix race condition in pg_ctl reading postmaster.pid. If postmaster changed postmaster.pid while pg_ctl was reading it, pg_ctl could overrun the buffer it allocated for the file. Fix by reading the whole file to memory with one read() call. initdb contains an identical copy of the readfile() function, but the files that initdb reads are static, not modified concurrently. Nevertheless, add a simple bounds-check there, if only to silence static analysis tools. Per report from Dave Vitek. Backpatch to all supported branches. 15 October 2012, 07:51:50 UTC
47232d7 Tom Lane 11 October 2012, 16:21:29 UTC Fix cross-type case in partial row matching for hashed subplans. When hashing a subplan like "WHERE (a, b) NOT IN (SELECT x, y FROM ...)", findPartialMatch() attempted to match rows using the hashtable's internal equality operators, which of course are for x and y's datatypes. What we need to use are the potentially cross-type operators for a=x, b=y, etc. Failure to do that leads to wrong answers or even crashes. The scope for problems is limited to cases where we have different types with compatible hash functions (else we'd not be using a hashed subplan), but for example int4 vs int8 can cause the problem. Per bug #7597 from Bo Jensen. This has been wrong since the hashed-subplan code was written, so patch all the way back. 11 October 2012, 16:21:29 UTC
3aa082f Tom Lane 10 October 2012, 01:04:30 UTC Fix PGXS support for building loadable modules on AIX. Building a shlib on AIX requires use of the mkldexport.sh script, but we failed to install that, preventing its use from non-source-tree contexts. Also, Makefile.aix had the wrong idea about where to find the installed copy of the postgres.imp symbol file used by AIX. Per report from John Pierce. Patch all the way back, since this has been broken since the beginning of PGXS. 10 October 2012, 01:04:30 UTC
36df743 Tom Lane 09 October 2012, 01:53:04 UTC Fix lo_import and lo_export to return useful error messages more often. I found that these functions tend to return -1 while leaving an empty error message string in the PGconn, if they suffer some kind of I/O error on the file. The reason is that lo_close, which thinks it's executed a perfectly fine SQL command, clears the errorMessage. The minimum-change workaround is to reorder operations here so that we don't fill the errorMessage until after lo_close. 09 October 2012, 01:53:04 UTC
d2fc891 Tom Lane 09 October 2012, 01:19:13 UTC Fix lo_export usage in example programs. lo_export returns -1, not zero, on failure. 09 October 2012, 01:19:13 UTC
27930be Tom Lane 04 October 2012, 17:41:19 UTC Fix permissions explanations in CREATE DATABASE and CREATE SCHEMA docs. These reference pages still claimed that you have to be superuser to create a database or schema owned by a different role. That was true before 8.1, but it was changed in commits aa1110624c08298393dfce996f7b21809d98d3fd and f91370cd2faf1fd35a1ac74d84652a85ed841919 to allow assignment of ownership to any role you are a member of. However, at the time we were thinking of that primarily as a change to the ALTER OWNER rules, so the need to touch these two CREATE ref pages got missed. 04 October 2012, 17:41:19 UTC
2a36a72 Alvaro Herrera 03 October 2012, 15:22:41 UTC REASSIGN OWNED: consider grants on tablespaces, too Apparently this was considered in the original code (see commit cec3b0a9) but I failed to notice that such entries would always be skipped by the database check at the start of the loop. Per bugs #7578 by Nikolay, #6116 by tushar.qa@gmail.com. 03 October 2012, 15:22:41 UTC
61540e6 Heikki Linnakangas 02 October 2012, 07:43:48 UTC Fix access past end of string in date parsing. This affects date_in(), and a couple of other funcions that use DecodeDate(). Hitoshi Harada 02 October 2012, 07:48:40 UTC
3dbd687 Tom Lane 29 September 2012, 21:57:05 UTC Fix bugs in "restore.sql" script emitted in pg_dump tar output. The tar output module did some very ugly and ultimately incorrect hacking on COPY commands to try to get them to work in the context of restoring a deconstructed tar archive. In particular, it would fail altogether for table names containing any upper-case characters, since it smashed the command string to lower-case before modifying it (and, just to add insult to injury, did that in a way that would fail in multibyte encodings). I don't see any particular value in being flexible about the case of the command keywords, since the string will just have been created by dumpTableData, so let's get rid of the whole case-folding thing. Also, it doesn't seem to meet the POLA for the script to restore data only in COPY mode, so add \i commands to make it have comparable behavior in --inserts mode. Noted while looking at the tar-output code in connection with Brian Weaver's patch. 29 September 2012, 21:57:05 UTC
ad721d0 Tom Lane 28 September 2012, 19:42:32 UTC Fix pg_restore to accept POSIX-conformant tar files. Back-patch portions of commit 05b555d12bc2ad0d581f48a12b45174db41dc10d. We need to patch pg_restore to accept either version of the magic string, in hopes of avoiding compatibility problems when 9.3 comes out. I also fixed pg_dump to write the correct 2-block EOF marker, since that won't create a compatibility problem with pg_restore and it could help with some versions of tar. Brian Weaver and Tom Lane 28 September 2012, 19:42:32 UTC
3b6460a Tom Lane 25 September 2012, 17:53:11 UTC Fix examples of how to use "su" while starting the server. The syntax "su -c 'command' username" is not accepted by all versions of su, for example not OpenBSD's. More portable is "su username -c 'command'". So change runtime.sgml to recommend that syntax. Also, add a -D switch to the OpenBSD example script, for consistency with other examples. Per Denis Lapshin and Gábor Hidvégi. 25 September 2012, 17:53:11 UTC
891155a Tom Lane 19 September 2012, 21:58:37 UTC Stamp 8.3.21. 19 September 2012, 21:58:37 UTC
a95c4a6 Tom Lane 19 September 2012, 21:39:07 UTC Update release notes for 9.2.1, 9.1.6, 9.0.10, 8.4.14, 8.3.21. 19 September 2012, 21:39:07 UTC
717606e Tom Lane 19 September 2012, 14:44:45 UTC Update time zone data files to tzdata release 2012f. DST law changes in Fiji. 19 September 2012, 14:46:10 UTC
8e21c38 Peter Eisentraut 19 September 2012, 04:08:46 UTC Translation updates 19 September 2012, 04:08:46 UTC
8bae564 Tom Lane 17 September 2012, 18:59:50 UTC Provide adequate documentation of the "table_name *" notation. Somewhere along the line, somebody decided to remove all trace of this notation from the documentation text. It was still in the command syntax synopses, or at least some of them, but with no indication what it meant. This will not do, as evidenced by the confusion apparent in bug #7543; even if the notation is now unnecessary, people will find it in legacy SQL code and need to know what it does. 17 September 2012, 18:59:50 UTC
9a699b7 Kevin Grittner 16 September 2012, 17:28:22 UTC Fix documentation reference to maximum allowed for autovacuum_freeze_max_age. The documentation mentioned setting autovacuum_freeze_max_age to "its maximum allowed value of a little less than two billion". This led to a post asking about the exact maximum allowed value, which is precisely two billion, not "a little less". Based on question by Radovan Jablonovsky. Backpatch to 8.3. 16 September 2012, 17:28:22 UTC
2734af4 Tom Lane 14 September 2012, 15:50:19 UTC Back-patch fix and test case for bug #7516. Back-patch commits 9afc6481117d2dd936e752da0424a2b6b05f6459 and b8fbbcf37f22c5e8361da939ad0fc4be18a34ca9. The first of these is really a minor code cleanup to save a few cycles, but it turns out to provide a workaround for the misoptimization problem described in bug #7516. The second commit adds a regression test case. Back-patch the fix to all active branches. The test case only works as far back as 9.0, because it relies on plpgsql which isn't installed by default before that. (I didn't have success modifying it into an all-plperl form that still provoked a crash, though this may just reflect my lack of Perl-fu.) 14 September 2012, 15:50:19 UTC
4da51c2 Tom Lane 10 September 2012, 00:33:14 UTC Make plperl safe against functions that are redefined while running. validate_plperl_function() supposed that it could free an old plperl_proc_desc struct immediately upon detecting that it was stale. However, if a plperl function is called recursively, this could result in deleting the struct out from under an outer invocation, leading to misbehavior or crashes. Add a simple reference-count mechanism to ensure that such structs are freed only when the last reference goes away. Per investigation of bug #7516 from Marko Tiikkaja. I am not certain that this error explains his report, because he says he didn't have any recursive calls --- but it's hard to see how else it could have crashed right there. In any case, this definitely fixes some problems in the area. Back-patch to all active branches. 10 September 2012, 00:33:14 UTC
63ea46f Robert Haas 06 September 2012, 19:43:46 UTC Fix "too many arguments" messages not to index off the end of argv[]. This affects initdb, clusterdb, reindexdb, and vacuumdb in master and 9.2; in earlier branches, only initdb is affected. 06 September 2012, 19:52:04 UTC
f98d8d5 Tom Lane 05 September 2012, 20:43:55 UTC Restore SIGFPE handler after initializing PL/Perl. Perl, for some unaccountable reason, believes it's a good idea to reset SIGFPE handling to SIG_IGN. Which wouldn't be a good idea even if it worked; but on some platforms (Linux at least) it doesn't work at all, instead resulting in forced process termination if the signal occurs. Given the lack of other complaints, it seems safe to assume that Perl never actually provokes SIGFPE and so there is no value in the setting anyway. Hence, reset it to our normal handler after initializing Perl. Report, analysis and patch by Andres Freund. 05 September 2012, 20:43:55 UTC
3d27e4d Tom Lane 31 August 2012, 03:48:27 UTC Back-patch recent fixes for gistchoose and gistRelocateBuildBuffersOnSplit. This back-ports commits c8ba697a4bdb934f0c51424c654e8db6133ea255 and e5db11c5582b469c04a11f217a0f32c827da5dd7, which fix one definite and one speculative bug in gistchoose, and make the code a lot more intelligible as well. In 9.2 only, this also affects the largely-copied-and-pasted logic in gistRelocateBuildBuffersOnSplit. The impact of the bugs was that the functions might make poor decisions as to which index tree branch to push a new entry down into, resulting in GiST index bloat and poor performance. The fixes rectify these decisions for future insertions, but a REINDEX would be needed to clean up any existing index bloat. Alexander Korotkov, Robert Haas, Tom Lane 31 August 2012, 03:48:27 UTC
588fb3f Robert Haas 30 August 2012, 17:26:45 UTC Add missing period to detail message. Per note from Peter Eisentraut. 30 August 2012, 17:27:42 UTC
9969e15 Tom Lane 23 August 2012, 21:25:38 UTC Fix cascading privilege revoke to notice when privileges are still held. If we revoke a grant option from some role X, but X still holds the option via another grant, we should not recursively revoke the privilege from role(s) Y that X had granted it to. This was supposedly fixed as one aspect of commit 4b2dafcc0b1a579ef5daaa2728223006d1ff98e9, but I must not have tested it, because in fact that code never worked: it forgot to shift the grant-option bits back over when masking the bits being revoked. Per bug #6728 from Daniel German. Back-patch to all active branches, since this has been wrong since 8.0. 23 August 2012, 21:25:38 UTC
3fe78ee Tom Lane 14 August 2012, 22:48:41 UTC Stamp 8.3.20. 14 August 2012, 22:48:41 UTC
2289dfe Tom Lane 14 August 2012, 22:24:27 UTC Update release notes for 9.1.5, 9.0.9, 8.4.13, 8.3.20. 14 August 2012, 22:34:21 UTC
27ac667 Tom Lane 14 August 2012, 22:28:58 UTC Prevent access to external files/URLs via contrib/xml2's xslt_process(). libxslt offers the ability to read and write both files and URLs through stylesheet commands, thus allowing unprivileged database users to both read and write data with the privileges of the database server. Disable that through proper use of libxslt's security options. Also, remove xslt_process()'s ability to fetch documents and stylesheets from external files/URLs. While this was a documented "feature", it was long regarded as a terrible idea. The fix for CVE-2012-3489 broke that capability, and rather than expend effort on trying to fix it, we're just going to summarily remove it. While the ability to write as well as read makes this security hole considerably worse than CVE-2012-3489, the problem is mitigated by the fact that xslt_process() is not available unless contrib/xml2 is installed, and the longstanding warnings about security risks from that should have discouraged prudent DBAs from installing it in security-exposed databases. Reported and fixed by Peter Eisentraut. Security: CVE-2012-3488 14 August 2012, 22:33:06 UTC
a4b0c0a Tom Lane 14 August 2012, 22:26:00 UTC Prevent access to external files/URLs via XML entity references. xml_parse() would attempt to fetch external files or URLs as needed to resolve DTD and entity references in an XML value, thus allowing unprivileged database users to attempt to fetch data with the privileges of the database server. While the external data wouldn't get returned directly to the user, portions of it could be exposed in error messages if the data didn't parse as valid XML; and in any case the mere ability to check existence of a file might be useful to an attacker. The ideal solution to this would still allow fetching of references that are listed in the host system's XML catalogs, so that documents can be validated according to installed DTDs. However, doing that with the available libxml2 APIs appears complex and error-prone, so we're not going to risk it in a security patch that necessarily hasn't gotten wide review. So this patch merely shuts off all access, causing any external fetch to silently expand to an empty string. A future patch may improve this. In HEAD and 9.2, also suppress warnings about undefined entities, which would otherwise occur as a result of not loading referenced DTDs. Previous branches don't show such warnings anyway, due to different error handling arrangements. Credit to Noah Misch for first reporting the problem, and for much work towards a solution, though this simplistic approach was not his preference. Also thanks to Daniel Veillard for consultation. Security: CVE-2012-3489 14 August 2012, 22:33:05 UTC
8d1f50e Peter Eisentraut 14 August 2012, 20:24:41 UTC Translation updates 14 August 2012, 20:24:41 UTC
4235419 Tom Lane 14 August 2012, 14:54:55 UTC Update time zone data files to tzdata release 2012e. DST law changes in Morocco; Tokelau has relocated to the other side of the International Date Line; and apparently Olson had Tokelau's GMT offset wrong by an hour even before that. There are also a large number of non-significant changes in this update. Upstream took the opportunity to remove trailing whitespace, and the SCCS-style version numbers on the individual files are gone too. 14 August 2012, 14:54:55 UTC
074bef8 Simon Riggs 08 August 2012, 20:07:35 UTC fsync backup_label after pg_start_backup() Dave Kerr, backpatched by Simon Riggs 08 August 2012, 20:07:35 UTC
8a88e57 Tom Lane 31 July 2012, 18:37:18 UTC Fix syslogger so that log_truncate_on_rotation works in the first rotation. In the original coding of the log rotation stuff, we did not bother to make the truncation logic work for the very first rotation after postmaster start (or after a syslogger crash and restart). It just always appended in that case. It did not seem terribly important at the time, but we've recently had two separate complaints from people who expected it to work unsurprisingly. (Both users tend to restart the postmaster about as often as a log rotation is configured to happen, which is maybe not typical use, but still...) Since the initial log file is opened in the postmaster, fixing this requires passing down some more state to the syslogger child process. It's always been like this, so back-patch to all supported branches. 31 July 2012, 18:37:18 UTC
53bc376 Tom Lane 27 July 2012, 23:31:38 UTC Improve reporting of error situations in find_other_exec(). This function suppressed any stderr output from the called program, which is unnecessary in the normal case and unhelpful in error cases. It also gave a rather opaque message along the lines of "fgets failure: Success" in case the called program failed to return anything on stdout. Since we've seen multiple reports of people not understanding what's wrong when pg_ctl reports this, improve the message. Back-patch to all active branches. 27 July 2012, 23:31:38 UTC
588586b Tom Lane 26 July 2012, 18:29:52 UTC Only allow autovacuum to be auto-canceled by a directly blocked process. In the original coding of the autovacuum cancel feature, commit acac68b2bcae818bc8803b8cb8cbb17eee8d5e2b, an autovacuum process was considered a target for cancellation if it was found to hard-block any process examined in the deadlock search. This patch tightens the test so that the autovacuum must directly hard-block the current process. This should make the behavior more predictable in general, and in particular it ensures that an autovacuum will not be canceled with less than deadlock_timeout grace period. In the old coding, it was possible for an autovacuum to be canceled almost instantly, given unfortunate timing of two or more other processes' lock attempts. This also justifies the logging methodology in the recent commit d7318d43d891bd63e82dcfc27948113ed7b1db80; without this restriction, that patch isn't providing enough information to see the connection of the canceling process to the autovacuum. Like that one, patch all the way back. 26 July 2012, 18:29:52 UTC
d2b93bf Tom Lane 26 July 2012, 18:22:53 UTC 8.3 doesn't have errdetail_log(). 26 July 2012, 18:22:53 UTC
618a0a6 Robert Haas 26 July 2012, 13:16:44 UTC Log a better message when canceling autovacuum. The old message was at DEBUG2, so typically it didn't show up in the log at all. As a result, in most cases where autovacuum was canceled, the only information that was logged was the table being vacuumed, with no indication as to what problem caused the cancel. Crank up the level to LOG and add some more details to assist with debugging. Back-patch all the way, per discussion on pgsql-hackers. 26 July 2012, 13:16:44 UTC
8468bcc Tom Lane 25 July 2012, 21:41:04 UTC Fix longstanding crash-safety bug with newly-created-or-reset sequences. If a crash occurred immediately after the first nextval() call for a serial column, WAL replay would restore the sequence to a state in which it appeared that no nextval() had been done, thus allowing the first sequence value to be returned again by the next nextval() call; as reported in bug #6748 from Xiangming Mei. More generally, the problem would occur if an ALTER SEQUENCE was executed on a freshly created or reset sequence. (The manifestation with serial columns was introduced in 8.2 when we added an ALTER SEQUENCE OWNED BY step to serial column creation.) The cause is that sequence creation attempted to save one WAL entry by writing out a WAL record that made it appear that the first nextval() had already happened (viz, with is_called = true), while marking the sequence's in-database state with log_cnt = 1 to show that the first nextval() need not emit a WAL record. However, ALTER SEQUENCE would emit a new WAL entry reflecting the actual in-database state (with is_called = false). Then, nextval would allocate the first sequence value and set is_called = true, but it would trust the log_cnt value and not emit any WAL record. A crash at this point would thus restore the sequence to its post-ALTER state, causing the next nextval() call to return the first sequence value again. To fix, get rid of the idea of logging an is_called status different from reality. This means that the first nextval-driven WAL record will happen at the first nextval call not the second, but the marginal cost of that is pretty negligible. In addition, make sure that ALTER SEQUENCE resets log_cnt to zero in any case where it touches sequence parameters that affect future nextval results. This will result in some user-visible changes in the contents of a sequence's log_cnt column, as reflected in the patch's regression test changes; but no application should be depending on that anyway, since it was already true that log_cnt changes rather unpredictably depending on checkpoint timing. In addition, make some basically-cosmetic improvements to get rid of sequence.c's undesirable intimacy with page layout details. It was always really trying to WAL-log the contents of the sequence tuple, so we should have it do that directly using a HeapTuple's t_data and t_len, rather than backing into it with some magic assumptions about where the tuple would be on the sequence's page. Back-patch to all supported branches. 25 July 2012, 21:41:04 UTC
038c36b Tom Lane 20 July 2012, 17:09:32 UTC Fix whole-row Var evaluation to cope with resjunk columns (again). When a whole-row Var is reading the result of a subquery, we need it to ignore any "resjunk" columns that the subquery might have evaluated for GROUP BY or ORDER BY purposes. We've hacked this area before, in commit 68e40998d058c1f6662800a648ff1e1ce5d99cba, but that fix only covered whole-row Vars of named composite types, not those of RECORD type; and it was mighty klugy anyway, since it just assumed without checking that any extra columns in the result must be resjunk. A proper fix requires getting hold of the subquery's targetlist so we can actually see which columns are resjunk (whereupon we can use a JunkFilter to get rid of them). So bite the bullet and add some infrastructure to make that possible. Per report from Andrew Dunstan and additional testing by Merlin Moncure. Back-patch to all supported branches. In 8.3, also back-patch commit 292176a118da6979e5d368a4baf27f26896c99a5, which for some reason I had not done at the time, but it's a prerequisite for this change. 20 July 2012, 17:09:32 UTC
9c2626a Tom Lane 17 July 2012, 20:56:08 UTC Improve coding around the fsync request queue. In all branches back to 8.3, this patch fixes a questionable assumption in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue that there are no uninitialized pad bytes in the request queue structs. This would only cause trouble if (a) there were such pad bytes, which could happen in 8.4 and up if the compiler makes enum ForkNumber narrower than 32 bits, but otherwise would require not-currently-planned changes in the widths of other typedefs; and (b) the kernel has not uniformly initialized the contents of shared memory to zeroes. Still, it seems a tad risky, and we can easily remove any risk by pre-zeroing the request array for ourselves. In addition to that, we need to establish a coding rule that struct RelFileNode can't contain any padding bytes, since such structs are copied into the request array verbatim. (There are other places that are assuming this anyway, it turns out.) In 9.1 and up, the risk was a bit larger because we were also effectively assuming that struct RelFileNodeBackend contained no pad bytes, and with fields of different types in there, that would be much easier to break. However, there is no good reason to ever transmit fsync or delete requests for temp files to the bgwriter/checkpointer, so we can revert the request structs to plain RelFileNode, getting rid of the padding risk and saving some marginal number of bytes and cycles in fsync queue manipulation while we are at it. The savings might be more than marginal during deletion of a temp relation, because the old code transmitted an entirely useless but nonetheless expensive-to-process ForgetRelationFsync request to the background process, and also had the background process perform the file deletion even though that can safely be done immediately. In addition, make some cleanup of nearby comments and small improvements to the code in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue. 17 July 2012, 20:56:08 UTC
b277a93 Tom Lane 15 July 2012, 17:28:32 UTC Prevent corner-case core dump in rfree(). rfree() failed to cope with the case that pg_regcomp() had initialized the regex_t struct but then failed to allocate any memory for re->re_guts (ie, the first malloc call in pg_regcomp() failed). It would try to touch the guts struct anyway, and thus dump core. This is a sufficiently narrow corner case that it's not surprising it's never been seen in the field; but still a bug is a bug, so patch all active branches. Noted while investigating whether we need to call pg_regfree after a failure return from pg_regcomp. Other than this bug, it turns out we don't, so adjust comments appropriately. 15 July 2012, 17:28:32 UTC
d2bb45d Tom Lane 10 July 2012, 22:00:55 UTC Back-patch fix for extraction of fixed prefixes from regular expressions. Back-patch of commits 628cbb50ba80c83917b07a7609ddec12cda172d0 and c6aae3042be5249e672b731ebeb21875b5343010. This has been broken since 7.3, so back-patch to all supported branches. 10 July 2012, 22:00:55 UTC
6b30408 Tom Lane 10 July 2012, 20:52:55 UTC Back-patch addition of pg_wchar-to-multibyte conversion functionality. Back-patch of commits 72dd6291f216440f6bb61a8733729a37c7e3b2d2, f6a05fd973a102f7e66c491d3f854864b8d24844, and 60e9c224a197aa37abb1aa3aefa3aad42da61f7f. This is needed to support fixing the regex prefix extraction bug in back branches. 10 July 2012, 20:52:55 UTC
1590731 Tom Lane 10 July 2012, 03:23:28 UTC Refactor pattern_fixed_prefix() to avoid dealing in incomplete patterns. Previously, pattern_fixed_prefix() was defined to return whatever fixed prefix it could extract from the pattern, plus the "rest" of the pattern. That definition was sensible for LIKE patterns, but not so much for regexes, where reconstituting a valid pattern minus the prefix could be quite tricky (certainly the existing code wasn't doing that correctly). Since the only thing that callers ever did with the "rest" of the pattern was to pass it to like_selectivity() or regex_selectivity(), let's cut out the middle-man and just have pattern_fixed_prefix's subroutines do this directly. Then pattern_fixed_prefix can return a simple selectivity number, and the question of how to cope with partial patterns is removed from its API specification. While at it, adjust the API spec so that callers who don't actually care about the pattern's selectivity (which is a lot of them) can pass NULL for the selectivity pointer to skip doing the work of computing a selectivity estimate. This patch is only an API refactoring that doesn't actually change any processing, other than allowing a little bit of useless work to be skipped. However, it's necessary infrastructure for my upcoming fix to regex prefix extraction, because after that change there won't be any simple way to identify the "rest" of the regex, not even to the low level of fidelity needed by regex_selectivity. We can cope with that if regex_fixed_prefix and regex_selectivity communicate directly, but not if we have to work within the old API. Hence, back-patch to all active branches. 10 July 2012, 03:23:28 UTC
7940028 Tom Lane 05 July 2012, 21:15:30 UTC Don't try to trim "../" in join_path_components(). join_path_components() tried to remove leading ".." components from its tail argument, but it was not nearly bright enough to do so correctly unless the head argument was (a) absolute and (b) canonicalized. Rather than try to fix that logic, let's just get rid of it: there is no correctness reason to remove "..", and cosmetic concerns can be taken care of by a subsequent canonicalize_path() call. Per bug #6715 from Greg Davidson. Back-patch to all supported branches. It appears that pre-9.2, this function is only used with absolute paths as head arguments, which is why we'd not noticed the breakage before. However, third-party code might be expecting this function to work in more general cases, so it seems wise to back-patch. In HEAD and 9.2, also make some minor cosmetic improvements to callers. 05 July 2012, 21:15:30 UTC
188a0a0 Tom Lane 30 June 2012, 20:44:19 UTC Prevent CREATE TABLE LIKE/INHERITS from (mis) copying whole-row Vars. If a CHECK constraint or index definition contained a whole-row Var (that is, "table.*"), an attempt to copy that definition via CREATE TABLE LIKE or table inheritance produced incorrect results: the copied Var still claimed to have the rowtype of the source table, rather than the created table. For the LIKE case, it seems reasonable to just throw error for this situation, since the point of LIKE is that the new table is not permanently coupled to the old, so there's no reason to assume its rowtype will stay compatible. In the inheritance case, we should ideally allow such constraints, but doing so will require nontrivial refactoring of CREATE TABLE processing (because we'd need to know the OID of the new table's rowtype before we adjust inherited CHECK constraints). In view of the lack of previous complaints, that doesn't seem worth the risk in a back-patched bug fix, so just make it throw error for the inheritance case as well. Along the way, replace change_varattnos_of_a_node() with a more robust function map_variable_attnos(), which is capable of being extended to handle insertion of ConvertRowtypeExpr whenever we get around to fixing the inheritance case nicely, and in the meantime it returns a failure indication to the caller so that a helpful message with some context can be thrown. Also, this code will do the right thing with subselects (if we ever allow them in CHECK or indexes), and it range-checks varattnos before using them to index into the map array. Per report from Sergey Konoplev. Back-patch to all supported branches. 30 June 2012, 20:44:19 UTC
ef0f9dd Robert Haas 26 June 2012, 10:40:58 UTC Backport fsync queue compaction logic to all supported branches. This backports commit 7f242d880b5b5d9642675517466d31373961cf98, except for the counter in pg_stat_bgwriter. The underlying problem (namely, that a full fsync request queue causes terrible checkpoint behavior) continues to be reported in the wild, and this code seems to be safe and robust enough to risk back-porting the fix. 26 June 2012, 10:47:41 UTC
b02cd9c Tom Lane 21 June 2012, 21:26:36 UTC Fix memory leak in ARRAY(SELECT ...) subqueries. Repeated execution of an uncorrelated ARRAY_SUBLINK sub-select (which I think can only happen if the sub-select is embedded in a larger, correlated subquery) would leak memory for the duration of the query, due to not reclaiming the array generated in the previous execution. Per bug #6698 from Armando Miraglia. Diagnosis and fix idea by Heikki, patch itself by me. This has been like this all along, so back-patch to all supported versions. 21 June 2012, 21:26:36 UTC
6d16507 Alvaro Herrera 18 June 2012, 20:37:49 UTC pg_dump: Fix verbosity level in LO progress messages In passing, reword another instance of the same message that was gratuitously different. Author: Josh Kupershmidt after a bug report by Bosco Rama 19 June 2012, 21:26:44 UTC
d117d23 Peter Eisentraut 19 June 2012, 18:32:51 UTC Update copyright year in forgotten places found by Stefan Kaltenbrunner 19 June 2012, 18:32:51 UTC
66fb03f Tom Lane 05 June 2012, 00:13:07 UTC Fix some more bugs in contrib/xml2's xslt_process(). It failed to check for error return from xsltApplyStylesheet(), as reported by Peter Gagarinov. (So far as I can tell, libxslt provides no convenient way to get a useful error message in failure cases. There might be some inconvenient way, but considering that this code is deprecated it's hard to get enthusiastic about putting lots of work into it. So I just made it say "failed to apply stylesheet", in line with the existing error checks.) While looking at the code I also noticed that the string returned by xsltSaveResultToString was never freed, resulting in a session-lifespan memory leak. Back-patch to all supported versions. 05 June 2012, 00:13:07 UTC
9ced013 Simon Riggs 01 June 2012, 11:59:54 UTC Avoid early reuse of btree pages, causing incorrect query results. When we allowed read-only transactions to skip assigning XIDs we introduced the possibility that a fully deleted btree page could be reused. This broke the index link sequence which could then lead to indexscans silently returning fewer rows than would have been correct. The actual incidence of silent errors from this is thought to be very low because of the exact workload required and locking pre-conditions. Fix is to remove pages only if index page opaque->btpo.xact precedes RecentGlobalXmin. Noah Misch, reviewed and backpatched by Simon Riggs 01 June 2012, 11:59:54 UTC
485e12f Tom Lane 31 May 2012, 23:14:08 UTC Stamp 8.3.19. 31 May 2012, 23:14:08 UTC
7f41a47 Tom Lane 31 May 2012, 23:03:57 UTC Update release notes for 9.1.4, 9.0.8, 8.4.12, 8.3.19. 31 May 2012, 23:03:57 UTC
c272fcd Peter Eisentraut 31 May 2012, 20:17:11 UTC Translation updates 31 May 2012, 20:17:11 UTC
back to top