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
1c635b0 Tom Lane 01 December 2011, 21:49:59 UTC Stamp 9.0.6. 01 December 2011, 21:49:59 UTC
da1eacb Tom Lane 01 December 2011, 21:39:07 UTC Clarify documentation about SQL:2008 variant of LIMIT/OFFSET syntax. The point that you need parentheses for non-constant expressions apparently needs to be brought out a bit more clearly, per bug #6315. 01 December 2011, 21:39:07 UTC
698bb4e Peter Eisentraut 01 December 2011, 20:59:40 UTC Translation updates 01 December 2011, 20:59:40 UTC
efb7423 Tom Lane 01 December 2011, 17:44:28 UTC Fix getTypeIOParam to support type record[]. Since record[] uses array_in, it needs to have its element type passed as typioparam. In HEAD and 9.1, this fix essentially reverts commit 9bc933b2125a5358722490acbc50889887bf7680, which was a hack that is no longer needed since domains don't set their typelem anymore. Before that, adjust the logic so that only domains are excluded from being treated like arrays, rather than assuming that only base types should be included. Add a regression test to demonstrate the need for this. Per report from Maxim Boguk. Back-patch to 8.4, where type record[] was added. 01 December 2011, 17:44:28 UTC
83c461e Tom Lane 01 December 2011, 01:55:10 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:10 UTC
33dcc3e Tom Lane 01 December 2011, 00:34:57 UTC Draft release notes for 9.1.2, 9.0.6, 8.4.10, 8.3.17, 8.2.23. 01 December 2011, 00:34:57 UTC
11fa083 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:48:36 UTC
b06c6f5 Tom Lane 30 November 2011, 05:37:20 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:20 UTC
75b6183 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. 29 November 2011, 21:51:28 UTC
d16ebde Tom Lane 28 November 2011, 18:52:09 UTC Remove erroneous claim about use of pg_locks.objid for advisory locks. The correct information appears in the text, so just remove the statement in the table, where it did not fit nicely anyway. (Curiously, the correct info has been there much longer than the erroneous table entry.) Resolves problem noted by Daniele Varrazzo. In HEAD and 9.1, also do a bit of wordsmithing on other text on the page. 28 November 2011, 18:52:09 UTC
62fa856 Andrew Dunstan 28 November 2011, 12:54:03 UTC Backpatch "Use the preferred version of xsubpp." As requested this is backpatched all the way to release 8.2. 28 November 2011, 12:54:03 UTC
b09fc7c Tom Lane 28 November 2011, 03:27:39 UTC Ensure that whole-row junk Vars are always of composite type. The EvalPlanQual machinery assumes that whole-row Vars generated for the outputs of non-table RTEs will be of composite types. However, for the case where the RTE is a function call returning a scalar type, we were doing the wrong thing, as a result of sharing code with a parser case where the function's scalar output is wanted. (Or at least, that's what that case has done historically; it does seem a bit inconsistent.) To fix, extend makeWholeRowVar's API so that it can support both use-cases. This fixes Belinda Cussen's report of crashes during concurrent execution of UPDATEs involving joins to the result of UNNEST() --- in READ COMMITTED mode, we'd run the EvalPlanQual machinery after a conflicting row update commits, and it was expecting to get a HeapTuple not a scalar datum from the "wholerowN" variable referencing the function RTE. Back-patch to 9.0 where the current EvalPlanQual implementation appeared. In 9.1 and up, this patch also fixes failure to attach the correct collation to the Var generated for a scalar-result case. An example: regression=# select upper(x.*) from textcat('ab', 'cd') x; ERROR: could not determine which collation to use for upper() function 28 November 2011, 03:27:39 UTC
87b0dcf Tom Lane 26 November 2011, 18:01:02 UTC Fix overly-aggressive and inconsistent quoting in OS X start script. Sidar Lopez, per bug #6310, with some additional improvements by me. Back-patch to 9.0, where the issue was introduced. 26 November 2011, 18:01:32 UTC
d1644d9 Bruce Momjian 25 November 2011, 19:34:51 UTC Allow pg_upgrade to upgrade clusters that use exclusion contraints by fixing pg_dump to properly preserve such indexes. Backpatch to 9.1 and 9.0 (where the bug was introduced). 25 November 2011, 19:39:18 UTC
80cbf34 Tom Lane 25 November 2011, 18:58:59 UTC Fix erroneous replay of GIN_UPDATE_META_PAGE WAL records. A simple thinko in ginRedoUpdateMetapage, namely failing to increment a loop counter, led to inserting records into the last pending-list page in the wrong order (the opposite of that intended). So far as I can tell, this would not upset the code that eventually flushes pending items into the main part of the GIN index. But it did break the code that searched the pending list for matches, resulting in transient failure to find matching entries during index lookups, as illustrated in bug #6307 from Maksym Boguk. Back-patch to 8.4 where the incorrect code was introduced. 25 November 2011, 18:59:22 UTC
3c4f293 Tom Lane 19 November 2011, 05:35:29 UTC Avoid floating-point underflow while tracking buffer allocation rate. When the system is idle for awhile after activity, the "smoothed_alloc" state variable in BgBufferSync converges slowly to zero. With standard IEEE float arithmetic this results in several iterations with denormalized values, which causes kernel traps and annoying log messages on some poorly-designed platforms. There's no real need to track such small values of smoothed_alloc, so we can prevent the kernel traps by forcing it to zero as soon as it's too small to be interesting for our purposes. This issue is purely cosmetic, since the iterations don't happen fast enough for the kernel traps to pose any meaningful performance problem, but still it seems worth shutting up the log messages. The kernel log messages were previously reported by a number of people, but kudos to Greg Matthews for tracking down exactly where they were coming from. 19 November 2011, 05:36:16 UTC
acbddf4 Michael Meskes 17 November 2011, 13:07:25 UTC Applied Zoltan's patch to correctly align interval and timestamp data in ecpg's sqlda. 17 November 2011, 13:43:49 UTC
90bbeb1 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:20 UTC
f72baf7 Michael Meskes 13 November 2011, 12:46:45 UTC Applied patch by Zoltan to fix copy&paste bug in ecpg's sqlda handling. 13 November 2011, 12:48:19 UTC
c49130a Tom Lane 10 November 2011, 23:37:00 UTC Throw nice error if server is too old to support psql's \ef or \sf command. Previously, you'd get "function pg_catalog.pg_get_functiondef(integer) does not exist", which is at best rather unprofessional-looking. Back-patch to 8.4 where \ef was introduced. Josh Kupershmidt 10 November 2011, 23:37:00 UTC
019d45e Robert Haas 10 November 2011, 23:00:34 UTC Correct documentation for trace_userlocks. 10 November 2011, 23:01:10 UTC
1d9d7a9 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, 18:55:39 UTC
a062ee4 Heikki Linnakangas 08 November 2011, 20:39:43 UTC Make DatumGetInetP() unpack inet datums with a 1-byte header, and add a new macro, DatumGetInetPP(), that does not. This brings these macros in line with other DatumGet*P() macros. Backpatch to 8.3, where 1-byte header varlenas were introduced. 08 November 2011, 20:45:28 UTC
0ff319d Peter Eisentraut 08 November 2011, 04:49:50 UTC -DLINUX_OOM_ADJ=0 should be in CPPFLAGS, not CFLAGS 08 November 2011, 04:51:01 UTC
d747a45 Tom Lane 07 November 2011, 16:48:53 UTC Fix assorted bugs in contrib/unaccent's configuration file parsing. Make it use t_isspace() to identify whitespace, rather than relying on sscanf which is known to get it wrong on some platform/locale combinations. Get rid of fixed-size buffers. Make it actually continue to parse the file after ignoring a line with untranslatable characters, as was obviously intended. The first of these issues is per gripe from J Smith, though not exactly either of his proposed patches. 07 November 2011, 16:49:17 UTC
b07b2bd Tom Lane 05 November 2011, 03:23:16 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:16 UTC
d8bff79 Peter Eisentraut 04 November 2011, 20:01:35 UTC Fix archive_command example The given archive_command example didn't use %p or %f, which wouldn't really work in practice. 04 November 2011, 20:03:45 UTC
3fbfd40 Tom Lane 03 November 2011, 23:17:59 UTC Fix bogus code in contrib/ tsearch dictionary examples. Both dict_int and dict_xsyn were blithely assuming that whatever memory palloc gives back will be pre-zeroed. This would typically work for just about long enough to run their regression tests, and no longer :-(. The pre-9.0 code in dict_xsyn was even lamer than that, as it would happily give back a pointer to the result of palloc(0), encouraging its caller to access off the end of memory. Again, this would just barely fail to fail as long as memory contained nothing but zeroes. Per a report from Rodrigo Hjort that code based on these examples didn't work reliably. 03 November 2011, 23:17:59 UTC
9b3c35a Tom Lane 03 November 2011, 21:53:26 UTC Fix inline_set_returning_function() to allow multiple OUT parameters. inline_set_returning_function failed to distinguish functions returning generic RECORD (which require a column list in the RTE, as well as run-time type checking) from those with multiple OUT parameters (which do not). This prevented inlining from happening. Per complaint from Jay Levitt. Back-patch to 8.4 where this capability was introduced. 03 November 2011, 21:53:26 UTC
42f7724 Tom Lane 02 November 2011, 17:36:31 UTC Revert "Stop btree indexscans upon reaching nulls in either direction." This reverts commit 7357f92a3ef1faff0ce85f55f3c5a7f4dc820eaa. As pointed out by Naoya Anzai, we need to do more work to make that idea handle end-of-index cases, and it is looking like too much risk for a back-patch. So bug #6278 is only going to be fixed in HEAD. 02 November 2011, 17:36:31 UTC
656bba9 Simon Riggs 02 November 2011, 08:52:59 UTC Derive oldestActiveXid at correct time for Hot Standby. There was a timing window between when oldestActiveXid was derived and when it should have been derived that only shows itself under heavy load. Move code around to ensure correct timing of derivation. No change to StartupSUBTRANS() code, which is where this failed. Bug report by Chris Redekop 02 November 2011, 08:52:59 UTC
ff8451a Simon Riggs 02 November 2011, 08:27:00 UTC Start Hot Standby faster when initial snapshot is incomplete. If the initial snapshot had overflowed then we can start whenever the latest snapshot is empty, not overflowed or as we did already, start when the xmin on primary was higher than xmax of our starting snapshot, which proves we have full snapshot data. Bug report by Chris Redekop 02 November 2011, 08:27:00 UTC
2f55c53 Simon Riggs 02 November 2011, 08:03:21 UTC Fix timing of Startup CLOG and MultiXact during Hot Standby Patch by me, bug report by Chris Redekop, analysis by Florian Pflug 02 November 2011, 08:03:21 UTC
7f797d2 Tom Lane 01 November 2011, 23:48:49 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:48:49 UTC
be5531c Magnus Hagander 01 November 2011, 14:44:26 UTC Document that multiple LDAP servers can be specified 01 November 2011, 14:45:22 UTC
7357f92 Tom Lane 31 October 2011, 20:40:16 UTC Stop btree indexscans upon reaching nulls in either direction. The existing scan-direction-sensitive tests were overly complex, and failed to stop the scan in cases where it's perfectly legitimate to do so. Per bug #6278 from Maksym Boguk. Back-patch to 8.3, which is as far back as the patch applies easily. Doesn't seem worth sweating over a relatively minor performance issue in 8.2 at this late date. (But note that this was a performance regression from 8.1 and before, so 8.2 is being left as an outlier.) 31 October 2011, 20:40:16 UTC
5093944 Tom Lane 29 October 2011, 18:31:03 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:03 UTC
0418bea Tom Lane 28 October 2011, 03:09:15 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:15 UTC
68b0997 Tom Lane 26 October 2011, 17:02:40 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:40 UTC
9fbb3ed Tom Lane 23 October 2011, 04:43:52 UTC Don't trust deferred-unique indexes for join removal. The uniqueness condition might fail to hold intra-transaction, and assuming it does can give incorrect query results. Per report from Marti Raudsepp, though this is not his proposed patch. Back-patch to 9.0, where both these features were introduced. In the released branches, add the new IndexOptInfo field to the end of the struct, to try to minimize ABI breakage for third-party code that may be examining that struct. 23 October 2011, 04:43:52 UTC
015cda4 Tom Lane 18 October 2011, 21:11:07 UTC Fix pg_dump to dump casts between auto-generated types. The heuristic for when to dump a cast failed for a cast between table rowtypes, as reported by Frédéric Rejol. Fix it by setting the "dump" flag for such a type the same way as the flag is set for the underlying table or base type. This won't result in the auto-generated type appearing in the output, since setting its objType to DO_DUMMY_TYPE unconditionally suppresses that. But it will result in dumpCast doing what was intended. Back-patch to 8.3. The 8.2 code is rather different in this area, and it doesn't seem worth any risk to fix a corner case that nobody has stumbled on before. 18 October 2011, 21:11:07 UTC
9ca46f5 Tom Lane 15 October 2011, 00:24:32 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:32 UTC
7ddd5bd Bruce Momjian 12 October 2011, 18:03:18 UTC Modify up/home macro to match standard parameter list; fixes doc build. 12 October 2011, 18:05:29 UTC
606990d 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:07 UTC
55800b6 Bruce Momjian 12 October 2011, 15:48:02 UTC Add Up/Home link to the top of the HTML doc output. Backpatch to 9.0.X and 9.1.X. 12 October 2011, 15:48:02 UTC
9c09e7c Robert Haas 10 October 2011, 17:10:47 UTC Fix typo in docs for libpq keepalives_count option. Shigehiro Honda 10 October 2011, 17:11:43 UTC
c02e52d 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:04 UTC
b77b601 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:10:19 UTC
ddc36df Tom Lane 04 October 2011, 21:00:17 UTC Add sourcefile/sourceline data to EXEC_BACKEND GUC transmission files. This oversight meant that on Windows, the pg_settings view would not display source file or line number information for values coming from postgresql.conf, unless the backend had received a SIGHUP since starting. In passing, also make the error detection in read_nondefault_variables a tad more thorough, and fix it to not lose precision on float GUCs (these changes are already in HEAD as of my previous commit). 04 October 2011, 21:01:06 UTC
f994bf9 Tom Lane 03 October 2011, 16:13:15 UTC ProcedureCreate neglected to record dependencies on default expressions. Thus, an object referenced in a default expression could be dropped while the function remained present. This was unaccountably missed in the original patch to add default parameters for functions. Reported by Pavel Stehule. 03 October 2011, 16:13:46 UTC
b07de20 Magnus Hagander 24 September 2011, 12:34:32 UTC Fix typo 24 September 2011, 12:35:08 UTC
05c4ef6 Magnus Hagander 24 September 2011, 12:29:37 UTC Note that sslmode=require verifies the CA if root cert is present This mode still exists for backwards compatibility, making sslmode=require the same as sslmode=verify-ca when the file is present, but not causing an error when it isn't. Per bug 6189, reported by Srinivas Aji 24 September 2011, 12:29:37 UTC
23f7df5 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:13:03 UTC
8522403 Tom Lane 22 September 2011, 22:00:48 UTC Stamp 9.0.5. 22 September 2011, 22:00:48 UTC
94a4195 Tom Lane 22 September 2011, 21:39:25 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:22 UTC
b43bb70 Peter Eisentraut 22 September 2011, 20:10:16 UTC Translation updates 22 September 2011, 20:10:16 UTC
b04214f Tom Lane 16 September 2011, 08:28:01 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:01 UTC
cac7332 Tom Lane 13 September 2011, 15:36:57 UTC deflist_to_tuplestore dumped core on an option with no value. Make it return NULL for the option_value, instead. Per report from Frank van Vugt. Back-patch to 8.4 where this code was added. 13 September 2011, 15:36:57 UTC
4de174d Tom Lane 11 September 2011, 17:17:12 UTC Fix permissions on pg_largeobject_metadata.h in 9.0 branch. For some reason it was 0755 instead of 0644. 11 September 2011, 17:17:12 UTC
ba24de1 Peter Eisentraut 08 September 2011, 19:09:08 UTC Add missing format argument to ecpg_log() call 08 September 2011, 19:10:43 UTC
6e7a3c3 Tom Lane 07 September 2011, 21:06:26 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:26 UTC
c3106a3 Bruce Momjian 07 September 2011, 18:42:36 UTC In pg_upgrade, disallow migration of 8.3 clusters using contrib/ltree because its internal format was changed in 8.4. Backpatch to 9.0 and 9.1. Report by depesz, diagnosis by Tom. 07 September 2011, 18:42:36 UTC
336059f Bruce Momjian 07 September 2011, 13:24:02 UTC Revert documentation patch about NEW/OLD and triggers. Backpatch to 9.0 and 9.1. Patch from Josh Kupershmidt. 07 September 2011, 13:24:02 UTC
a443343 Bruce Momjian 07 September 2011, 02:54:19 UTC Properly document the existance of OLD/NEW trigger pl/pgsql trigger fields. Backpatch to 9.0 and 9.1. Report from Pavel Stehule, patch from Josh Kupershmidt 07 September 2011, 02:54:19 UTC
665af1a Bruce Momjian 06 September 2011, 19:20:17 UTC Fix plpgsql "PERFORM" markup. Backpatch to 9.0 and 9.1. 06 September 2011, 19:20:49 UTC
d5e429b Tom Lane 06 September 2011, 18:50:28 UTC Avoid possibly accessing off the end of memory in SJIS2004 conversion. The code in shift_jis_20042euc_jis_2004() would fetch two bytes even when only one remained in the string. Since conversion functions aren't supposed to assume null-terminated input, this poses a small risk of fetching 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. Report and patch by Noah Misch. 06 September 2011, 18:50:56 UTC
ad1e827 Tom Lane 06 September 2011, 18:35:36 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:37:48 UTC
dcc728e Bruce Momjian 06 September 2011, 17:41:32 UTC Document PERFORM limitation when using WITH queries. Backpatch to 9.0 and 9.1. Report from depstein@alliedtesting.com. 06 September 2011, 17:42:00 UTC
0154332 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:06 UTC
38052a9 Bruce Momjian 06 September 2011, 15:08:35 UTC Properly document semphore requirements by accounting for worker processes. Backpatch to 9.1 and 9.0. Submitted by Anton Yuzhaninov, confirmed by Robert Haas 06 September 2011, 15:08:35 UTC
e6d4288 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:47:03 UTC
3de09dd Bruce Momjian 05 September 2011, 17:24:47 UTC Document that contrib/pgtrgm only processes ASCII alphanumeric characters. Backpatch to 9.0 and 9.1. 05 September 2011, 17:24:47 UTC
ed7eff8 Tom Lane 05 September 2011, 00:07:42 UTC Guard against using plperl's Makefile without specifying --with-perl. The $(PERL) macro will be set by configure if it finds perl at all, but $(perl_privlibexp) isn't configured unless you said --with-perl. This results in confusing error messages if someone cd's into src/pl/plperl and tries to build there despite the configure omission, as reported by Tomas Vondra in bug #6198. Add simple checks to provide a more useful report, while not disabling other use of the makefile such as "make clean". Back-patch to 9.0, which is as far as the patch applies easily. 05 September 2011, 00:07:42 UTC
0962182 Tom Lane 03 September 2011, 20:17:44 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:17:44 UTC
2cda30e Michael Meskes 02 September 2011, 07:45:11 UTC Fix brace indentation of commit f8c74422010e63506fa69635ea61920bc042b70e to fit PostgreSQL style. 02 September 2011, 07:48:19 UTC
f8c7442 Michael Meskes 01 September 2011, 13:27:38 UTC In ecpglib restore LC_NUMERIC in case of an error. 01 September 2011, 13:31:16 UTC
a02e409 Heikki Linnakangas 01 September 2011, 06:13:37 UTC Move the line to undefine setlocale() macro on Win32 outside USE_REPL_SNPRINTF ifdef block. It has nothing to do with whether the replacement snprintf function is used. It caused no live bug, because the replacement snprintf function is always used on Win32, but it was nevertheless misplaced. 01 September 2011, 06:18:27 UTC
3505862 Tom Lane 01 September 2011, 04:18:39 UTC Further repair of eqjoinsel ndistinct-clamping logic. Examination of examples provided by Mark Kirkwood and others has convinced me that actually commit 7f3eba30c9d622d1981b1368f2d79ba0999cdff2 was quite a few bricks shy of a load. The useful part of that patch was clamping ndistinct for the inner side of a semi or anti join, and the reason why that's needed is that it's the only way that restriction clauses eliminating rows from the inner relation can affect the estimated size of the join result. I had not clearly understood why the clamping was appropriate, and so mis-extrapolated to conclude that we should clamp ndistinct for the outer side too, as well as for both sides of regular joins. These latter actions were all wrong, and are reverted with this patch. In addition, the clamping logic is now made to affect the behavior of both paths in eqjoinsel_semi, with or without MCV lists to compare. When we have MCVs, we suppose that the most common values are the ones that are most likely to survive the decimation resulting from a lower restriction clause, so we think of the clamping as eliminating non-MCV values, or potentially even the least-common MCVs for the inner relation. Back-patch to 8.4, same as previous fixes in this area. 01 September 2011, 04:20:05 UTC
e724b96 Bruce Momjian 01 September 2011, 01:50:00 UTC Fix pg_upgrade to preserve toast relfrozenxids for old 8.3 servers. This fixes a pg_upgrade bug that could lead to query errors when clog files are improperly removed. Backpatch to 8.4, 9.0, 9.1. 01 September 2011, 01:50:00 UTC
53434c6 Tom Lane 31 August 2011, 20:04:58 UTC Improve eqjoinsel's ndistinct clamping to work for multiple levels of join. This patch fixes an oversight in my commit 7f3eba30c9d622d1981b1368f2d79ba0999cdff2 of 2008-10-23. That patch accounted for baserel restriction clauses that reduced the number of rows coming out of a table (and hence the number of possibly-distinct values of a join variable), but not for join restriction clauses that might have been applied at a lower level of join. To account for the latter, look up the sizes of the min_lefthand and min_righthand inputs of the current join, and clamp with those in the same way as for the base relations. Noted while investigating a complaint from Ben Chobot, although this in itself doesn't seem to explain his report. Back-patch to 8.4; previous versions used different estimation methods for which this heuristic isn't relevant. 31 August 2011, 20:04:58 UTC
047f205 Tom Lane 30 August 2011, 18:49:57 UTC Fix a missed case in code for "moving average" estimate of reltuples. It is possible for VACUUM to scan no pages at all, if the visibility map shows that all pages are all-visible. In this situation VACUUM has no new information to report about the relation's tuple density, so it wasn't changing pg_class.reltuples ... but it updated pg_class.relpages anyway. That's wrong in general, since there is no evidence to justify changing the density ratio reltuples/relpages, but it's particularly bad if the previous state was relpages=reltuples=0, which means "unknown tuple density". We just replaced "unknown" with "zero". ANALYZE would eventually recover from this, but it could take a lot of repetitions of ANALYZE to do so if the relation size is much larger than the maximum number of pages ANALYZE will scan, because of the moving-average behavior introduced by commit b4b6923e03f4d29636a94f6f4cc2f5cf6298b8c8. The only known situation where we could have relpages=reltuples=0 and yet the visibility map asserts everything's visible is immediately following a pg_upgrade. It might be advisable for pg_upgrade to try to preserve the relpages/reltuples statistics; but in any case this code is wrong on its own terms, so fix it. Per report from Sergey Koposov. Back-patch to 8.4, where the visibility map was introduced, same as the previous change. 30 August 2011, 18:49:57 UTC
2de0fde Tom Lane 29 August 2011, 02:27:48 UTC Actually, all of parallel restore's limitations should be tested earlier. On closer inspection, whining in restore_toc_entries_parallel is really much too late for any user-facing error case. The right place to do it is at the start of RestoreArchive(), before we've done anything interesting (suh as trying to DROP all the targets ...) Back-patch to 8.4, where parallel restore was introduced. 29 August 2011, 02:28:10 UTC
fbf776a Tom Lane 29 August 2011, 01:48:58 UTC Be more user-friendly about unsupported cases for parallel pg_restore. If we are unable to do a parallel restore because the input file is stdin or is otherwise unseekable, we should complain and fail immediately, not after having done some of the restore. Complaining once per thread isn't so cool either, and the messages should be worded to make it clear this is an unsupported case not some weird race-condition bug. Per complaint from Lonni Friedman. Back-patch to 8.4, where parallel restore was introduced. 29 August 2011, 01:49:21 UTC
42de04f Tom Lane 27 August 2011, 20:37:08 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:08 UTC
431b638 Tom Lane 27 August 2011, 18:16:25 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:25 UTC
20139f4 Tom Lane 26 August 2011, 20:51:46 UTC Fix potential memory clobber in tsvector_concat(). tsvector_concat() allocated its result workspace using the "conservative" estimate of the sum of the two input tsvectors' sizes. Unfortunately that wasn't so conservative as all that, because it supposed that the number of pad bytes required could not grow. Which it can, as per test case from Jesper Krogh, if there's a mix of lexemes with positions and lexemes without them in the input data. The fix is to assume that we might add a not-previously-present pad byte for each and every lexeme in the two inputs; which really is conservative, but it doesn't seem worthwhile to try to be more precise. This is an aboriginal bug in tsvector_concat, so back-patch to all versions containing it. 26 August 2011, 20:51:46 UTC
df957a7 Bruce Momjian 26 August 2011, 04:12:39 UTC In pg_upgrade, limit schema name filter to include toast tables. Bug introduced recently when trying to filter out temp tables. Backpatch to 9.0 and 9.1. 26 August 2011, 04:12:39 UTC
9354f5b Tom Lane 25 August 2011, 18:33:08 UTC Fix psql lexer to avoid use of backtracking. Per previous experimentation, backtracking slows down lexing performance significantly (by about a third). It's usually pretty easy to avoid, just need to have rules that accept an incomplete construct and do whatever the lexer would have done otherwise. The backtracking was introduced by the patch that added quoted variable substitution. Back-patch to 9.0 where that was added. 25 August 2011, 18:33:37 UTC
b7cd5c8 Robert Haas 25 August 2011, 16:37:32 UTC Properly quote SQL/MED generic options in pg_dump output. Shigeru Hanada 25 August 2011, 16:38:06 UTC
8a32c94 Tom Lane 25 August 2011, 03:50:20 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:20 UTC
7ec0258 Heikki Linnakangas 23 August 2011, 08:55:21 UTC Add recovery.conf to the index in the user manual. Fujii Masao 23 August 2011, 08:57:43 UTC
52120ee Tom Lane 21 August 2011, 22:16:08 UTC Fix trigger WHEN conditions when both BEFORE and AFTER triggers exist. Due to tuple-slot mismanagement, evaluation of WHEN conditions for AFTER ROW UPDATE triggers could crash if there had been a BEFORE ROW trigger fired for the same update. Fix by not trying to overload the use of estate->es_trig_tuple_slot. Per report from Yoran Heling. Back-patch to 9.0, when trigger WHEN conditions were introduced. 21 August 2011, 22:16:08 UTC
706493a 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:32 UTC
d4c2425 Peter Eisentraut 18 August 2011, 09:53:32 UTC Change PyInit_plpy to external linkage Module initialization functions in Python 3 must have external linkage, because PyMODINIT_FUNC does dllexport on Windows-like platforms. Without this change, the build with Python 3 fails on Windows. 18 August 2011, 10:47:35 UTC
1853e12 Tom Lane 16 August 2011, 19:26:35 UTC Forget about targeting catalog cache invalidations by tuple TID. The TID isn't stable enough: we might queue an sinval event before a VACUUM FULL, and then process it afterwards, when the target tuple no longer has the same TID. So we must invalidate entries on the basis of hash value only. The old coding can be shown to result in various bizarre, hard-to-reproduce errors in the presence of concurrent VACUUM FULLs on system catalogs, and could easily result in permanent catalog corruption, up to and including complete loss of tables. This commit is just a minimal fix that removes the unsafe comparison. We should remove transmission of the tuple TID from sinval messages altogether, and then arrange to suppress the extra message in the common case of a heap_update that doesn't change the key hashvalue. But that's going to be much more invasive, and will only produce a probably-marginal performance gain, so it doesn't seem like material for a back-patch. Back-patch to 9.0. Before that, VACUUM FULL refused to do any tuple moving if it found any INSERT_IN_PROGRESS or DELETE_IN_PROGRESS tuples (and CLUSTER would give up altogether), so there was no risk of moving a tuple that might be the subject of an unsent sinval message. 16 August 2011, 19:26:35 UTC
38ef2e2 Tom Lane 16 August 2011, 18:38:35 UTC Fix incorrect order of operations during sinval reset processing. We have to be sure that we have revalidated each nailed-in-cache relcache entry before we try to use it to load data for some other relcache entry. The introduction of "mapped relations" in 9.0 broke this, because although we updated the state kept in relmapper.c early enough, we failed to propagate that information into relcache entries soon enough; in particular, we could try to fetch pg_class rows out of pg_class before we'd updated its relcache entry's rd_node.relNode value from the map. This bug accounts for Dave Gould's report of failures after "vacuum full pg_class", and I believe that there is risk for other system catalogs as well. The core part of the fix is to copy relmapper data into the relcache entries during "phase 1" in RelationCacheInvalidate(), before they'll be used in "phase 2". To try to future-proof the code against other similar bugs, I also rearranged the order in which nailed relations are visited during phase 2: now it's pg_class first, then pg_class_oid_index, then other nailed relations. This should ensure that RelationClearRelation can apply RelationReloadIndexInfo to all nailed indexes without risking use of not-yet-revalidated relcache entries. Back-patch to 9.0 where the relation mapper was introduced. 16 August 2011, 18:38:35 UTC
44b6d53 Tom Lane 16 August 2011, 17:48:16 UTC Preserve toast value OIDs in toast-swap-by-content for CLUSTER/VACUUM FULL. This works around the problem that a catalog cache entry might contain a toast pointer that we try to dereference just as a VACUUM FULL completes on that catalog. We will see the sinval message on the cache entry when we acquire lock on the toast table, but by that point we've already told tuptoaster.c "here's the pointer to fetch", so it's difficult from a code structural standpoint to update the pointer before we use it. Much less painful to ensure that toast pointers are not invalidated in the first place. We have to add a bit of code to deal with the case that a value that previously wasn't toasted becomes so; but that should be a seldom-exercised corner case, so the inefficiency shouldn't be significant. Back-patch to 9.0. In prior versions, we didn't allow CLUSTER on system catalogs, and VACUUM FULL didn't result in reassignment of toast OIDs, so there was no problem. 16 August 2011, 17:48:16 UTC
93519b0 Tom Lane 16 August 2011, 17:12:10 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:10 UTC
f239ec5 Bruce Momjian 16 August 2011, 02:39:38 UTC In pg_upgrade, avoid dumping orphaned temporary tables. This makes the pg_upgrade schema matching pattern match pg_dump/pg_dumpall. Fix for 9.0, 9.1, and 9.2. 16 August 2011, 02:39:38 UTC
5707f35 Tom Lane 14 August 2011, 19:40:36 UTC Fix unsafe order of operations in foreign-table DDL commands. When updating or deleting a system catalog tuple, it's necessary to acquire RowExclusiveLock on the catalog before looking up the tuple; otherwise a concurrent VACUUM FULL on the catalog might move the tuple to a different TID before we can apply the update. Coding patterns that find the tuple via a table scan aren't at risk here, but when obtaining the tuple from a catalog cache, correct ordering is important; and several routines in foreigncmds.c got it wrong. Noted while running the regression tests in parallel with VACUUM FULL of assorted system catalogs. For consistency I moved all the heap_open calls to the starts of their functions, including a couple for which there was no actual bug. Back-patch to 8.4 where foreigncmds.c was added. 14 August 2011, 19:40:36 UTC
back to top