https://github.com/postgres/postgres

sort by:
Revision Author Date Message Commit Date
7e23229 tag 8.2.13 13 March 2009, 02:16:43 UTC
e9e4316 Update back-branch release notes. 12 March 2009, 22:36:09 UTC
14e504b Fix core dump due to null-pointer dereference in to_char() when datetime format codes are misapplied to a numeric argument. (The code still produces a pretty bogus error message in such cases, but I'll settle for stopping the crash for now.) Per bug #4700 from Sergey Burladyan. Problem exists in all supported branches, so patch all the way back. In HEAD, also clean up some ugly coding in the nearby cache management code. 12 March 2009, 00:53:41 UTC
9424b22 Prevent recursion during parse of email-like string with multiple '@'. Patch by Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> 10 March 2009, 17:44:44 UTC
20bef21 Add MUST (Mauritius Island Summer Time) to the list of known abbreviations. Mauritius began using DST in the summer 2008-2009; the Olson library has been updated already. Xavier Bugaud 05 March 2009, 14:28:18 UTC
6faf291 Put back our old workaround for machines that declare cbrt() in math.h but fail to provide the function itself. Not sure how we escaped testing anything later than 7.3 on such cases, but they still exist, as per André Volpato's report about AIX 5.3. 04 March 2009, 22:08:34 UTC
c5d6081 Ooops ... fix some confusion between gettext() and _() in my previous patch. This has moved around in past releases, so just copying-and-pasting from HEAD didn't work as intended. 03 March 2009, 00:17:22 UTC
78206b3 When we are in error recursion trouble, arrange to suppress translation and encoding conversion of any elog/ereport message being sent to the frontend. This generalizes a patch that I put in last October, which suppressed translation of only specific messages known to be associated with recursive can't-translate-the-message behavior. As shown in bug #4680, we need a more general answer in order to have some hope of coping with broken encoding conversion setups. This approach seems a good deal less klugy anyway. Patch in all supported branches. 02 March 2009, 21:18:57 UTC
8fcdac9 Fix usage of char2wchar/wchar2char. Changes: - pg_wchar and wchar_t could have different size, so char2wchar doesn't call pg_mb2wchar_with_len to prevent out-of-bound memory bug - make char2wchar/wchar2char symmetric, now they should not be called with C-locale because mbstowcs/wcstombs oftenly doesn't work correct with C-locale. - Text parser uses pg_mb2wchar_with_len directly in case of C-locale and multibyte encoding Per bug report by Hiroshi Inoue <inoue@tpf.co.jp> and following discussion. Backpatch up to 8.2 when multybyte support was implemented in tsearch. 02 March 2009, 15:13:17 UTC
08a0989 Fix buffer allocations in encoding conversion routines so that they won't fail on zero-length inputs. This isn't an issue in normal use because the conversion infrastructure skips calling the converters for empty strings. However a problem was created by yesterday's patch to check whether the right conversion function is supplied in CREATE CONVERSION. The most future-proof fix seems to be to make the converters safe for this corner case. 28 February 2009, 18:50:01 UTC
03ead2a In CREATE CONVERSION, test that the given function is a valid conversion function for the specified source and destination encodings. We do that by calling the function with an empty string. If it can't perform the requested conversion, it will throw an error. Backport to 7.4 - 8.3. Per bug report #4680 by Denis Afonin. 27 February 2009, 16:35:36 UTC
faa0b60 Set isnull for errm and sqlstate local variables when they're free'd. Because they are out of scope for any code after that anyway, leaving isnull true should be harmless. However, PL/pgSQL Debugger doesn't seem to care about the scoping and crashed, per report by Robert Walker (bug #4635). And it's good to be tidy for debugging purposes too. Fix in 8.3, 8.2 and 8.1 branches, CVS HEAD was fixed earlier already. Analysis and fix by Ashesh Vashi and Dave Page. 27 February 2009, 10:27:45 UTC
d3247ae Fix an old problem in decompilation of CASE constructs: the ruleutils.c code looks for a CaseTestExpr to figure out what the parser did, but it failed to consider the possibility that an implicit coercion might be inserted above the CaseTestExpr. This could result in an Assert failure in some cases (but correct results if Asserts weren't enabled), or an "unexpected CASE WHEN clause" error in other cases. Per report from Alan Li. Back-patch to 8.1; problem doesn't exist before that because CASE was implemented differently. 25 February 2009, 18:00:14 UTC
b8fcef6 Repair a longstanding bug in CLUSTER and the rewriting variants of ALTER TABLE: if the command is executed by someone other than the table owner (eg, a superuser) and the table has a toast table, the toast table's pg_type row ends up with the wrong typowner, ie, the command issuer not the table owner. This is quite harmless for most purposes, since no interesting permissions checks consult the pg_type row. However, it could lead to unexpected failures if one later tries to drop the role that issued the command (in 8.1 or 8.2), or strange warnings from pg_dump afterwards (in 8.3 and up, which will allow the DROP ROLE because we don't create a "redundant" owner dependency for table rowtypes). Problem identified by Cott Lang. Back-patch to 8.1. The problem is actually far older --- the CLUSTER variant can be demonstrated in 7.0 --- but it's mostly cosmetic before 8.1 because we didn't track ownership dependencies before 8.1. Also, fixing it before 8.1 would require changing the call signature of heap_create_with_catalog(), which seems to carry a nontrivial risk of breaking add-on modules. 24 February 2009, 01:39:01 UTC
37a8cc3 Loop calling CallNamedPipe() several times in case it fails, since it can be transient failures, causing kill() to not properly send signals. Original patch from Steve Marshall, modified by me. 15 February 2009, 13:58:20 UTC
9692582 Fix plpgsql to not treat INSERT INTO as an INTO-variables clause anywhere in the string, not just at the start. Per bug #4629 from Martin Blazek. Back-patch to 8.2; prior versions don't have the problem, at least not in the reported case, because they don't try to recognize INTO in non-SELECT statements. (IOW, this is really fallout from the RETURNING patch.) 02 February 2009, 20:25:50 UTC
e06e3d3 Defend against null input in analyze_requires_snapshot(), per report from Rushabh Lathia. Back-patch of patch of 2009-01-08. This is necessary in 8.3, as reported by Bjorn Munch. It's not currently necessary in 8.2, AFAICS, but seems best to include it there too. 30 January 2009, 16:59:16 UTC
fbb70cc tag 8.2.12 30 January 2009, 03:13:35 UTC
2e28cf0 Update back-branch release notes. 30 January 2009, 00:37:52 UTC
678fecb Translation updates 29 January 2009, 22:06:53 UTC
e43ffd9 Update time zone data files to tzdata release 2009a: introduces Asia/Kathmandu as the preferred spelling of that zone name, corrects historical DST information for Switzerland and Cuba. 29 January 2009, 20:00:14 UTC
31fb149 Replace argument-checking Asserts with regular test-and-elog checks in all encoding conversion functions. These are not can't-happen cases because it's possible to create a conversion with the wrong conversion function for the specified encoding pair. That would lead to an Assert crash in an Assert-enabled build, or incorrect conversion otherwise, neither of which is desirable. This would be a DOS issue if production databases were customarily built with asserts enabled, but fortunately that's not so. Per an observation by Heikki. Back-patch to all supported branches. 29 January 2009, 19:24:19 UTC
3364386 Go over all OpenSSL return values and make sure we compare them to the documented API value. The previous code got it right as it's implemented, but accepted too much/too little compared to the API documentation. Per comment from Zdenek Kotala. 28 January 2009, 15:06:55 UTC
7b44608 Fix erroneous memory context switch in autovacuum, which was returning to a context long after it had been destroyed. Per problem report from Justin Pasher. Patch by Tom Lane and me. 8.3 and later do not have this bug, because this code has been restructured for unrelated reasons. In 8.2 it does not manifest as a crash, but it still seems safer fixing it nonetheless. 20 January 2009, 12:17:23 UTC
d7adf1b Change explanation of pg_switch_xlog()'s return value to match code. 15 January 2009, 18:23:53 UTC
22abc26 Fix URL generation in headline. Only tag lexeme will be replaced by space. Per http://archives.postgresql.org/pgsql-bugs/2008-12/msg00013.php 15 January 2009, 17:44:47 UTC
32cfb33 Fix generation of too long headline with ShortWords. Per http://archives.postgresql.org/pgsql-hackers/2008-09/msg01088.php 15 January 2009, 17:44:18 UTC
963b87c Remove broken Assertions that failed if a statement executed in PL/pgSQL is rewritten into another kind of statement, for example if an INSERT is rewritten into an UPDATE. Back-patch to 8.3 and 8.2. For HEAD, Tom suggested inventing a new SPI_OK_REWRITTEN return code, but that's not a backportable solution. I'll do that as a separate patch, this patch will do as a stopgap measure for HEAD too in the meanwhile. 14 January 2009, 09:53:57 UTC
63ca96a Throw an error when using -C and -1 at the same time in pg_restore. It's not possible to do CREATE DATABASE inside a transaction, so previously we just got a server error instead. Backpatch to 8.2, which is where the -1 feature appeared. 13 January 2009, 11:45:01 UTC
c165c25 Update release notes for 8.3.5, 8.2.11, and 8.1.15 to mention the need to reindex GiST indexes: If you were running a previous 8.X.X release, REINDEX all GiST indexes after the upgrade. 09 January 2009, 01:46:48 UTC
c23bd92 Insert conditional SPI_push/SPI_pop calls into InputFunctionCall, OutputFunctionCall, and friends. This allows SPI-using functions to invoke datatype I/O without concern for the possibility that a SPI-using function will be called (which could be either the I/O function itself, or a function used in a domain check constraint). It's a tad ugly, but not nearly as ugly as what'd be needed to make this work via retail insertion of push/pop operations in all the PLs. This reverts my patch of 2007-01-30 that inserted some retail SPI_push/pop calls into plpgsql; that approach only fixed plpgsql, and not any other PLs. But the other PLs have the issue too, as illustrated by a recent gripe from Christian Schröder. Back-patch to 8.2, which is as far back as this solution will work. It's also as far back as we need to worry about the domain-constraint case, since earlier versions did not attempt to check domain constraints within datatype input. I'm not aware of any old I/O functions that use SPI themselves, so this should be sufficient for a back-patch. 07 January 2009, 20:39:15 UTC
7673ed2 Remove references to pgsql-ports and pgsql-patches mailing lists from various documentation, since those lists are now dead/deprecated. Point to pgsql-bugs and/or pgsql-hackers as appropriate. 06 January 2009, 17:27:39 UTC
1740947 Fix logic in lazy vacuum to decide if it's worth trying to truncate the heap. If the table was smaller than REL_TRUNCATE_FRACTION (= 16) pages, we always tried to acquire AccessExclusiveLock on it even if there was no empty pages at the end. Report by Simon Riggs. Back-patch all the way to 7.4. 06 January 2009, 14:55:50 UTC
e4dcb11 Fix bug per Oleksiy Shchukin - 2nd argument for dblink_get_result(text,bool) is PG_GETARG_BOOL(2), should be PG_GETARG_BOOL(1). Apply simple fix to back branches only. More extensive change to be applied to head per Tom's suggestion. 03 January 2009, 19:58:10 UTC
e581c04 Make heap_update() set newtup->t_tableOid correctly, for consistency with the other major heapam.c functions. The only known consequence of this omission is that UPDATE RETURNING failed to return the correct value for "tableoid", as per report from KaiGai Kohei. Back-patch to 8.2. Arguably it's wrong all the way back; but without evidence of visible breakage before RETURNING was added, I'll desist from patching the older branches. 16 December 2008, 16:26:21 UTC
7ae3c0f Fix failure to ensure that a snapshot is available to datatype input functions when they are invoked by the parser. We had been setting up a snapshot at plan time but really it needs to be done earlier, before parse analysis. Per report from Dmitry Koterov. Also fix two related problems discovered while poking at this one: exec_bind_message called datatype input functions without establishing a snapshot, and SET CONSTRAINTS IMMEDIATE could call trigger functions without establishing a snapshot. Backpatch to 8.2. The underlying problem goes much further back, but it is masked in 8.1 and before because we didn't attempt to invoke domain check constraints within datatype input. It would only be exposed if a C-language datatype input function used the snapshot; which evidently none do, or we'd have heard complaints sooner. Since this code has changed a lot over time, a back-patch is hardly risk-free, and so I'm disinclined to patch further than absolutely necessary. 13 December 2008, 02:00:53 UTC
4914b70 Fix an oversight in the code that makes transitive-equality deductions from outer join clauses. Given, say, ... from a left join b on a.a1 = b.b1 where a.a1 = 42; we'll deduce a clause b.b1 = 42 and then mark the original join clause redundant (we can't remove it completely for reasons I don't feel like squeezing into this log entry). However the original implementation of that wasn't bulletproof, because clause_selectivity() wouldn't honor this_selec if given nonzero varRelid --- which in practice meant that it worked as desired *except* when considering index scan quals. Which resulted in bogus underestimation of the size of the indexscan result for an inner indexscan in an outer join, and consequently a possibly bad choice of indexscan vs. bitmap scan. Fix by introducing an explicit test into clause_selectivity(). Also, to make sure we don't trigger that test in corner cases, change the convention to be that this_selec > 1, not this_selec = 1, means it's been marked redundant. Per trouble report from Scara Maccai. Back-patch to 8.2, where the problem was introduced. 01 December 2008, 21:06:31 UTC
ad807ff Ensure that the contents of a holdable cursor don't depend on out-of-line toasted values, since those could get dropped once the cursor's transaction is over. Per bug #4553 from Andrew Gierth. Back-patch as far as 8.1. The bug actually exists back to 7.4 when holdable cursors were introduced, but this patch won't work before 8.1 without significant adjustments. Given the lack of field complaints, it doesn't seem worth the work (and risk of introducing new bugs) to try to make a patch for the older branches. 01 December 2008, 17:06:35 UTC
eea4890 Fix dblink and tablefunc to not return with the wrong CurrentMemoryContext. Per buildfarm results. 30 November 2008, 23:24:08 UTC
25a4f1a Remove inappropriate memory context switch in shutdown_MultiFuncCall(). This was a thinko introduced in a patch from last February; it results in memory leakage if an SRF is shut down before the actual end of query, because subsequent code will be running in a longer-lived context than it's expecting to be. 30 November 2008, 18:49:48 UTC
66156f2 information_schema.key_column_usage.position_in_unique_constraint was misdocumented as not being implemented. In reality it has worked since the release of 8.2. 25 November 2008, 20:47:55 UTC
734b27d In predtest.c, install a limit on the number of branches we will process in AND, OR, or equivalent clauses: if there are too many (more than 100) just exit without proving anything. This ensures that we don't spend O(N^2) time trying (and most likely failing) to prove anything about very long IN lists and similar cases. Also, install a couple of CHECK_FOR_INTERRUPTS calls to ensure that a long proof attempt can be interrupted. Per gripe from Sergey Konoplev. Back-patch the whole patch to 8.2 and just the CHECK_FOR_INTERRUPTS addition to 8.1. (The rest of the patch doesn't apply cleanly, and since 8.1 doesn't show the complained-of behavior anyway, it doesn't seem necessary to work hard on it.) 12 November 2008, 23:08:50 UTC
dc1b318 Detect and error out on inability to get proper linkage information required for plperl, usually due to absence of perl ExtUtils::Embed module. Backpatch as far as 8.1. 12 November 2008, 00:00:53 UTC
5aa7042 Get rid of adjust_appendrel_attr_needed(), which has been broken ever since we extended the appendrel mechanism to support UNION ALL optimization. The reason nobody noticed was that we are not actually using attr_needed data for appendrel children; hence it seems more reasonable to rip it out than fix it. Back-patch to 8.2 because an Assert failure is possible in corner cases. Per examination of an example from Jim Nasby. In HEAD, also get rid of AppendRelInfo.col_mappings, which is quite inadequate to represent UNION ALL situations; depend entirely on translated_vars instead. 11 November 2008, 18:13:54 UTC
8f74153 Fix old bug in contrib/sslinfo: X509_NAME_to_text freed the BIO_s_mem buffer it was using too soon. In a situation where pg_do_encoding_conversion is a no-op, this led to garbage data returned. In HEAD, also modify the code that's ensuring null termination to make it a tad more obvious what's happening. 10 November 2008, 14:57:53 UTC
400e915 tag 8.2.11 31 October 2008, 02:44:09 UTC
614b828 Update back-branch release notes. 30 October 2008, 22:22:57 UTC
a137de4 Translation updates 30 October 2008, 20:12:35 UTC
a3ee41d Update time zone data files to tzdata release 2008i (DST law changes in Argentina, Brazil, Mauritius, Syria). 30 October 2008, 13:17:09 UTC
bbe385e Missing space in error message 30 October 2008, 12:25:32 UTC
3e86678 Install a more robust solution for the problem of infinite error-processing recursion when we are unable to convert a localized error message to the client's encoding. We've been over this ground before, but as reported by Ibrar Ahmed, it still didn't work in the case of conversion failures for the conversion-failure message itself :-(. Fix by installing a "circuit breaker" that disables attempts to localize this message once we get into recursion trouble. Patch all supported branches, because it is in fact broken in all of them; though I had to add some missing translations to the older branches in order to expose the failure in the particular test case I was using. 27 October 2008, 19:37:36 UTC
0ee91fd Better solution to the IN-list issue: instead of having an arbitrary cutoff, treat Var and non-Var IN-list items differently. Only non-Var items are candidates to go into an ANY(ARRAY) construct --- we put all Vars as separate OR conditions on the grounds that that leaves more scope for optimization. Per suggestion from Robert Haas. 26 October 2008, 02:46:36 UTC
038e45d Add a heuristic to transformAExprIn() to make it prefer expanding "x IN (list)" into an OR of equality comparisons, rather than x = ANY(ARRAY[...]), when there are Vars in the right-hand side. This avoids a performance regression compared to pre-8.2 releases, in cases where the OR form can be optimized into scans of multiple indexes. Limit the possible downside by preferring this form only when the list isn't very long (I set the cutoff at 32 elements, which is a bit arbitrary but in the right ballpark). Per discussion with Jim Nasby. In passing, also make it try the OR form if it cannot select a common type for the array elements; we've seen a complaint or two about how the OR form worked for such cases and ARRAY doesn't. 25 October 2008, 17:19:26 UTC
642257c Fix an old bug in after-trigger handling: AfterTriggerEndQuery took the address of afterTriggers->query_stack[afterTriggers->query_depth] and hung onto it through all its firings of triggers. However, if a trigger causes sufficiently many nested query executions, query_stack will get repalloc'd bigger, leaving AfterTriggerEndQuery --- and hence afterTriggerInvokeEvents --- using a stale pointer. So far as I can find, the only consequence of this error is to stomp on a couple of words of already-freed memory; which would lead to a failure only if that chunk had already gotten re-allocated for something else. So it's hard to exhibit a simple failure case, but this is surely a bug. I noticed this while working on my recent patch to reduce pending-trigger space usage. The present patch is mighty ugly, because it requires making afterTriggerInvokeEvents know about all the possible event lists it might get called on. Fortunately, this is only needed in back branches because CVS HEAD avoids the problem in a different way: afterTriggerInvokeEvents only touches the passed AfterTriggerEventList pointer once at startup. Back branches are stable enough that wiring in knowledge of all possible call usages doesn't seem like a killer problem. Back-patch to 8.0. 7.4's trigger code is completely different and doesn't seem to have the problem (it doesn't even use repalloc). 25 October 2008, 03:32:51 UTC
8a47932 Fix GiST's killing tuple: GISTScanOpaque->curpos wasn't correctly set. As result, killtuple() marks as dead wrong tuple on page. Bug was introduced by me while fixing possible duplicates during GiST index scan. 22 October 2008, 12:55:59 UTC
f189a12 Fix small bug in headline generation. Patch from Sushant Sinha <sushant354@gmail.com> http://archives.postgresql.org/pgsql-hackers/2008-07/msg00785.php 17 October 2008, 17:40:14 UTC
741c3b0 Fix a small memory leak in ExecReScanAgg() in the hashed aggregation case. In the previous coding, the list of columns that needed to be hashed on was allocated in the per-query context, but we reallocated every time the Agg node was rescanned. Since this information doesn't change over a rescan, just construct the list of columns once during ExecInitAgg(). 16 October 2008, 19:26:01 UTC
b55073d Fix SPI_getvalue and SPI_getbinval to range-check the given attribute number according to the TupleDesc's natts, not the number of physical columns in the tuple. The previous coding would do the wrong thing in cases where natts is different from the tuple's column count: either incorrectly report error when it should just treat the column as null, or actually crash due to indexing off the end of the TupleDesc's attribute array. (The second case is probably not possible in modern PG versions, due to more careful handling of inheritance cases than we once had. But it's still a clear lack of robustness here.) The incorrect error indication is ignored by all callers within the core PG distribution, so this bug has no symptoms visible within the core code, but it might well be an issue for add-on packages. So patch all the way back. 16 October 2008, 13:23:34 UTC
c564931 Fix COPY documentation to not imply that HEADER can be used outside CSV mode. Per gripe from Bill Thoen. 10 October 2008, 21:46:49 UTC
cd85846 Optional arguments should be optional. 10 October 2008, 12:19:47 UTC
68909e7 Fix overly tense optimization of PLpgSQL_func_hashkey: we must represent the isTrigger state explicitly, not rely on nonzero-ness of trigrelOid to indicate trigger-hood, because trigrelOid will be left zero when compiling for validation. The (useless) function hash entry built by the validator was able to match an ordinary non-trigger call later in the same session, thereby bypassing the check that is supposed to prevent such a call. Per report from Alvaro. It might be worth suppressing the useless hash entry altogether, but that's a bigger change than I want to consider back-patching. Back-patch to 8.0. 7.4 doesn't have the problem because it doesn't have validation mode. 09 October 2008, 16:35:19 UTC
433ba2d When a relation is moved to another tablespace, we can't assume that we can use the old relfilenode in the new tablespace. There might be another relation in the new tablespace with the same relfilenode, so we must generate a fresh relfilenode in the new tablespace. The 8.3 patch to let deleted relation files linger as zero-length files until the next checkpoint made this more obvious: moving a relation from one table space another, and then back again, caused a collision with the lingering file. Back-patch to 8.1. The issue is present in 8.0 as well, but it doesn't seem worth fixing there, because we didn't have protection from OID collisions after OID wraparound before 8.1. Report by Guillaume Lelarge. 07 October 2008, 11:15:54 UTC
05da8a6 Fix improper display of fractional seconds in interval values when using --enable-integer-datetimes and a non-ISO datestyle. Ron Mayer 02 October 2008, 13:47:50 UTC
9eba4c3 Recent patches to pg_ctl broke "pg_ctl restart" for the case where no command-line options had been given to the postmaster; and just plain broke it altogether in 8.1 and 8.0. Per report from KaiGai Kohei. 30 September 2008, 13:14:15 UTC
a36a20a Fix more problems with rewriter failing to set Query.hasSubLinks when inserting a SubLink expression into a rule query. We missed cases where the original query contained a sub-SELECT in a function in FROM, a multi-row VALUES list, or a RETURNING list. Per bug #4434 from Dean Rasheed and subsequent investigation. Back-patch to 8.1; older releases don't have the issue because they didn't try to be smart about setting hasSubLinks only when needed. 24 September 2008, 16:53:00 UTC
c4e5ec5 Make sure pg_control is opened in binary mode, to deal with situtations when the file contains an EOF maker (0x1A) on Windows. ITAGAKI Takahiro 24 September 2008, 08:59:44 UTC
6967e89 tag for 8.2.10 19 September 2008, 03:12:08 UTC
c82cf66 Update back-branch release notes. 19 September 2008, 02:45:33 UTC
466c89e Update time zone data files to tzdata release 2008f (DST law changes in Argentina, Bahamas, Brazil, Mauritius, Morocco, Pakistan, Palestine, Paraguay). 17 September 2008, 14:18:55 UTC
6d4b3f1 Widen the nLocks counts in local lock tables from int to int64. This forestalls potential overflow when the same table (or other object, but usually tables) is accessed by very many successive queries within a single transaction. Per report from Michael Milligan. Back-patch to 8.0, which is as far back as the patch conveniently applies. There have been no reports of overflow in pre-8.3 releases, but clearly the risk existed all along. (Michael's report suggests that 8.3 may consume lock counts faster than prior releases, but with no test case to look at it's hard to be sure about that. Widening the counts seems a good future-proofing measure in any event.) 16 September 2008, 01:56:43 UTC
49b505f Initialize the minimum frozen Xid in vac_update_datfrozenxid using GetOldestXmin() instead of RecentGlobalXmin; this is safer because we do not depend on the latter being correctly set elsewhere, and while it is more expensive, this code path is not performance-critical. This is a real risk for autovacuum, because it can execute whole cycles without doing a single vacuum, which would mean that RecentGlobalXmin would stay at its initialization value, FirstNormalTransactionId, causing a bogus value to be inserted in pg_database. This bug could explain some recent reports of failure to truncate pg_clog. At the same time, change the initialization of RecentGlobalXmin to InvalidTransactionId, and ensure that it's set to something else whenever it's going to be used. Using it as FirstNormalTransactionId in HOT page pruning could incur in data loss. InitPostgres takes care of setting it to a valid value, but the extra checks are there to prevent "special" backends from behaving in unusual ways. Per Tom Lane's detailed problem dissection in 29544.1221061979@sss.pgh.pa.us 11 September 2008, 14:01:16 UTC
d22e47d Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this. 01 September 2008, 22:30:48 UTC
063ec6c Fix pg_dump docs to acknowledge that you can use -Z with plain text output. Pointed out by Daniel Migowski. 26 August 2008, 00:03:30 UTC
e414175 Fix possible duplicate tuples while GiST scan. Now page is processed at once and ItemPointers are collected in memory. Remove tuple's killing by killtuple() if tuple was moved to another page - it could produce unaceptable overhead. Backpatch up to 8.1 because the bug was introduced by GiST's concurrency support. 23 August 2008, 10:41:38 UTC
7ddd839 Make libpq on windows not try to send chunks larger than 64Kb. Per Microsoft knowledge base article Q201213, early versions of Windows fail when we do this. Later versions of Windows appear to have a higher limit than 64Kb, but do still fail on large sends, so we unconditionally limit it for all versions. Patch from Tom Lane. 20 August 2008, 11:53:49 UTC
8ca6a92 Fix pg_dump/pg_restore's ExecuteSqlCommand() to behave suitably if PQexec returns NULL instead of a PGresult. The former coding would fail, which is OK, but it neglected to give you the PQerrorMessage that might tell you why. In the oldest branches, there was another problem: it'd sometimes report PQerrorMessage from the wrong connection. 16 August 2008, 02:25:17 UTC
f44f0ea Fix pull_up_simple_union_all to copy all rtable entries from child subquery to parent, not only those with RangeTblRefs. We need them in ExecCheckRTPerms. Report by Brendan O'Shea. Back-patch to 8.2, where pull_up_simple_union_all was introduced. 14 August 2008, 20:32:11 UTC
1a3970f Install checks in executor startup to ensure that the tuples produced by an INSERT or UPDATE will match the target table's current rowtype. In pre-8.3 releases inconsistency can arise with stale cached plans, as reported by Merlin Moncure. (We patched the equivalent hazard on the SELECT side in Feb 2007; I'm not sure why we thought there was no risk on the insertion side.) In 8.3 and HEAD this problem should be impossible due to plan cache invalidation management, but it seems prudent to make the check anyway. Back-patch as far as 8.0. 7.x versions lack ALTER COLUMN TYPE, so there seems no way to abuse a stale plan comparably. 08 August 2008, 17:01:26 UTC
aab9979 Do not allow Unique nodes to be scanned backwards. The code claimed that it would work, but in fact it didn't return the same rows when moving backwards as when moving forwards. This would have no visible effect in a DISTINCT query (at least assuming the column datatypes use a strong definition of equality), but it gave entirely wrong answers for DISTINCT ON queries. 05 August 2008, 21:28:42 UTC
a1b631b Fix parsing of LDAP URLs so it doesn't reject spaces in the "suffix" part. Per report from César Miguel Oliveira Alves. 24 July 2008, 17:52:09 UTC
32e409b Update link to Oleg and Teodor's GIN page. (Extracted from fast-insert patch, since it ought to be back-patched) 22 July 2008, 22:05:42 UTC
9f66d52 Fix an oversight in the original implementation of performMultipleDeletions(): the alreadyDeleted list has to be passed down through deleteDependentObjects(), else objects that are deleted via auto/internal dependencies don't get reported back up to performMultipleDeletions(). Depending on the visitation order, this could cause the code to try to delete an already-deleted object, leading to strange errors in DROP OWNED (typically "cache lookup failed for relation NNNNN" or similar). Per bug #4289. Patch for back branches only. This code has recently been rewritten in HEAD, and doesn't have this particular bug anymore. 11 July 2008, 16:08:57 UTC
51ca7bd Fix mis-calculation of extParam/allParam sets for plan nodes, as seen in bug #4290. The fundamental bug is that masking extParam by outer_params, as finalize_plan had been doing, caused us to lose the information that an initPlan depended on the output of a sibling initPlan. On reflection the best thing to do seemed to be not to try to adjust outer_params for this case but get rid of it entirely. The only thing it was really doing for us was to filter out param IDs associated with SubPlan nodes, and that can be done (with greater accuracy) while processing individual SubPlan nodes in finalize_primnode. This approach was vindicated by the discovery that the masking method was hiding a second bug: SS_finalize_plan failed to remove extParam bits for initPlan output params that were referenced in the main plan tree (it only got rid of those referenced by other initPlans). It's not clear that this caused any real problems, given the limited use of extParam by the executor, but it's certainly not what was intended. I originally thought that there was also a problem with needing to include indirect dependencies on external params in initPlans' param sets, but it turns out that the executor handles this correctly so long as the depended-on initPlan is earlier in the initPlans list than the one using its output. That seems a bit of a fragile assumption, but it is true at the moment, so I just documented it in some code comments rather than making what would be rather invasive changes to remove the assumption. Back-patch to 8.1. Previous versions don't have the case of initPlans referring to other initPlans' outputs, so while the existing logic is still questionable for them, there are not any known bugs to be fixed. So I'll refrain from changing them for now. 10 July 2008, 01:17:44 UTC
c3c76c2 Fix performance bug in write_syslog(): the code to preferentially break the log message at newlines cost O(N^2) for very long messages with few or no newlines. For messages in the megabyte range this became the dominant cost. Per gripe from Achilleas Mantzios. Patch all the way back, since this is a safe change with no portability risks. I am also thinking of increasing PG_SYSLOG_LIMIT, but that should be done separately. 08 July 2008, 22:17:55 UTC
1b3dfb0 Fix estimate_num_groups() to assume that GROUP BY expressions yielding boolean results always contribute two groups, regardless of the expression contents. This is very substantially more accurate than the regular heuristic for certain boolean tests like "col IS NULL". Per gripe from Sam Mason. Back-patch to all supported releases, since the behavior of estimate_num_groups() hasn't changed all that much since 7.4. 07 July 2008, 20:25:14 UTC
495d327 Fix AT TIME ZONE (in all three variants) so that we first try to interpret the timezone argument as a timezone abbreviation, and only try it as a full timezone name if that fails. The zic database has four zones (CET, EET, MET, WET) that are full daylight-savings zones and yet have names that are the same as their abbreviations for standard time, resulting in ambiguity. In the timestamp input functions we resolve the ambiguity by preferring the abbreviation, and AT TIME ZONE should work the same way. (No functionality is lost because the zic database also has other names for these zones, eg Europe/Zurich.) Per gripe from Jaromir Talir. Backpatch to 8.1. Older releases did not have the issue because AT TIME ZONE only accepted abbreviations not zone names. (Thus, this patch also arguably fixes a compatibility botch introduced at 8.1: in ambiguous cases we now behave the same as 8.0 did.) 07 July 2008, 18:10:03 UTC
5b924b1 Prevent integer overflows during units conversion when displaying a GUC variable that has units. Per report from Stefan Kaltenbrunner. Backport to 8.2. I also backported my patch of 2007-06-21 that prevented comparable overflows on the input side, since that now seems to have enough field track record to be back-patched safely. That patch included addition of hints listing the available unit names, which I did not bother to strip out of it --- this will make a little more work for the translators, but they can copy the translation from 8.3, and anyway an untranslated hint is better than no hint. 06 July 2008, 19:49:02 UTC
0c27e58 Fix identify_system_timezone() so that it tests the behavior of the system timezone setting in the current year and for 100 years back, rather than always examining years 1904-2004. The original coding would have problems distinguishing zones whose behavior diverged only after 2004; which is a situation we will surely face sometime, if it's not out there already. In passing, also prevent selection of the dummy "Factory" timezone, even if that's exactly what the system is using. Reporting time as GMT seems better than that. 01 July 2008, 03:41:10 UTC
feeac41 Fix 'pg_ctl reload' to properly preserve postmaster commend-line arguments on restart. Patch to releases 8.0 - 8.3.X. 27 June 2008, 01:53:20 UTC
b5ea5e2 Clean up a number of bogosities around pltcl's handling of the Tcl "result": 1. Directly reading interp->result is deprecated in Tcl 8.0 and later; you're supposed to use Tcl_GetStringResult. This code finally broke with Tcl 8.5, because Tcl_GetVar can now have side-effects on interp->result even though it preserves the logical state of the result. (There's arguably a Tcl issue here, because Tcl_GetVar could invalidate the pointer result of a just-preceding Tcl_GetStringResult, but I doubt the Tcl guys will see it as a bug.) 2. We were being sloppy about the encoding of the result: some places would push database-encoding data into the Tcl result, which should not happen, and we were assuming that any error result coming back from Tcl was in the database encoding, which is not a good assumption. 3. There were a lot of calls of Tcl_SetResult that uselessly specified TCL_VOLATILE for constant strings. This is only a minor performance issue, but I fixed it in passing since I had to look at all the calls anyway. #2 is a live bug regardless of which Tcl version you are interested in, so back-patch even to branches that are unlikely to be used with Tcl 8.5. I went back as far as 8.0, which is as far as the patch applied easily; 7.4 was using a different error processing scheme that has got its own problems :-( 17 June 2008, 00:52:56 UTC
1720960 Fix bug in the WAL recovery code to finish an incomplete split. CacheInvalidateRelcache() crashes if called in WAL recovery, because the invalidation infrastructure hasn't been initialized yet. Back-patch to 8.2, where the bug was introduced. 11 June 2008, 08:42:35 UTC
a7aaa49 Create a script to handle stamping release version numbers into files, replacing the tedious and error-prone manual process we've been using. 10 June 2008, 18:09:01 UTC
2dee38d Fix datetime input functions to correctly detect integer overflow when running on a 64-bit platform ... strtol() will happily return 64-bit output in that case. Per bug #4231 from Geoff Tolley. 09 June 2008, 19:34:16 UTC
da3a1b7 tag 8.2.9 09 June 2008, 00:34:32 UTC
ea83cc1 Stamp 8.2.9 (except for configure.in/configure) 08 June 2008, 22:14:31 UTC
414d4b8 Update release notes for ALTER AGGREGATE fix. 08 June 2008, 21:46:26 UTC
af55dc8 ALTER AGGREGATE OWNER seems to have been missed by the last couple of patches that dealt with object ownership. It wasn't updating pg_shdepend nor adjusting the aggregate's ACL. In 8.2 and up, fix this permanently by making it use AlterFunctionOwner_oid. In 8.1, the function code wasn't factored that way, so just copy and paste. 08 June 2008, 21:09:59 UTC
742627a Update release notes for 8.3.3 et al. 07 June 2008, 22:10:57 UTC
7340246 Fix pg_get_ruledef() so that negative numeric constants are parenthesized. This is needed because :: casting binds more tightly than minus, so for example -1::integer is not the same as (-1)::integer, and there are cases where the difference is important. In particular this caused a failure in SELECT DISTINCT ... ORDER BY ... where expressions that should have matched were seen as different by the parser; but I suspect that there could be other cases where failure to parenthesize leads to subtler semantic differences in reloaded rules. Per report from Alexandr Popov. 06 June 2008, 17:59:45 UTC
b33c197 tag 8.2.8 06 June 2008, 04:03:08 UTC
back to top