aboutsummaryrefslogtreecommitdiff
path: root/src/backend
Commit message (Collapse)AuthorAge
* Install a search tree depth limit in GIN bulk-insert operations, to preventTom Lane2009-03-24
| | | | | | | | | | | | them from degrading badly when the input is sorted or nearly so. In this scenario the tree is unbalanced to the point of becoming a mere linked list, so insertions become O(N^2). The easiest and most safely back-patchable solution is to stop growing the tree sooner, ie limit the growth of N. We might later consider a rebalancing tree algorithm, but it's not clear that the benefit would be worth the cost and complexity. Per report from Sergey Burladyan and an earlier complaint from Heikki. Back-patch to 8.2; older versions didn't have GIN indexes.
* Fix Windows-specific race condition in syslogger. This could've beenHeikki Linnakangas2009-03-18
| | | | | | | | | | | the cause of the "could not write to log file: Bad file descriptor" errors reported at http://archives.postgresql.org//pgsql-general/2008-06/msg00193.php Backpatch to 8.3, the race condition was introduced by the CSV logging patch. Analysis and patch by Gurjeet Singh.
* Translation updatesPeter Eisentraut2009-03-12
|
* Fix core dump due to null-pointer dereference in to_char() when datetimeTom Lane2009-03-12
| | | | | | | | | | 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.
* Remove pg_trace.h inclusion from c.h and add it to the .c files that need it.Alvaro Herrera2009-03-11
| | | | | | | | | Only needed in 8.3 because it's already this way in HEAD, and older branches did not support DTrace. This allows external modules to compile on Linux machines where SystemTap support was recently added, when the required SystemTap headers are not present on the build machine. Approach suggested by Tom, after a RPM build trouble report by Devrim Gunduz.
* Fix set_subquery_pathlist() to copy the RTE's subquery before it gets mangledTom Lane2009-03-10
| | | | | | | | | | | | | | | | by the planning process. This prevents the "failed to locate grouping columns" error recently reported by Dickson Guedes. That happens because planning replaces SubLinks by SubPlans in the subquery's targetlist, and exprTypmod() is smarter about the former than the latter, causing the apparent type of the subquery's output columns to change. This seems to be a deficiency we should fix in exprTypmod(), but that will be a much more invasive patch with possible side-effects elsewhere, so I'll do that only in HEAD. Back-patch to 8.3. Arguably the lack of a copying step is broken/dangerous all the way back, but in the absence of known problems I'll refrain from making the older branches pay the extra cost. (The reason this particular symptom didn't appear before is that exprTypmod() wasn't smart about SubLinks either, until 8.3.)
* Prevent recursion during parse of email-like string with multiple '@'.Teodor Sigaev2009-03-10
| | | | Patch by Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
* Put back our old workaround for machines that declare cbrt() in math.h butTom Lane2009-03-04
| | | | | | 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.
* Ooops ... fix some confusion between gettext() and _() in my previous patch.Tom Lane2009-03-03
| | | | | This has moved around in past releases, so just copying-and-pasting from HEAD didn't work as intended.
* When we are in error recursion trouble, arrange to suppress translation andTom Lane2009-03-02
| | | | | | | | | | | 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.
* Fix usage of char2wchar/wchar2char. Changes:Teodor Sigaev2009-03-02
| | | | | | | | | | | | | | | | - 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.
* Don't mangle xml and xpath unless xml is not in fact a well-formed document, ↵Andrew Dunstan2009-02-28
| | | | in xpath(). If mangling xpath, make a saner attempt where xpath expression does not begin with '/'.
* Fix buffer allocations in encoding conversion routines so that they won'tTom Lane2009-02-28
| | | | | | | | 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.
* In CREATE CONVERSION, test that the given function is a valid conversionHeikki Linnakangas2009-02-27
| | | | | | | | 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.
* Fix an old problem in decompilation of CASE constructs: the ruleutils.c codeTom Lane2009-02-25
| | | | | | | | | | | 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.
* Repair a longstanding bug in CLUSTER and the rewriting variants of ALTERTom Lane2009-02-24
| | | | | | | | | | | | | | | | | | 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.
* Fix UNLISTEN to fall out quickly if the current backend has never executedTom Lane2009-02-13
| | | | | | | | | | | | any LISTEN command. This is more important than it used to be because DISCARD ALL invokes UNLISTEN. Connection-pooled applications making heavy use of DISCARD ALL were seeing significant contention for pg_listener, as reported by Matteo Beccati. It seems unlikely that clients using LISTEN would use pooled connections, so this simple tweak seems sufficient, especially since the pg_listener implementation is slated to go away soon anyway. Back-patch to 8.3, where DISCARD ALL was introduced.
* Defend against null input in analyze_requires_snapshot(), per reportTom Lane2009-01-30
| | | | | | | | 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.
* Translation updatesPeter Eisentraut2009-01-29
|
* Replace argument-checking Asserts with regular test-and-elog checks in allTom Lane2009-01-29
| | | | | | | | | | | | 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.
* Fix incorrect dereferencing of char* to array's index.Teodor Sigaev2009-01-29
| | | | Per Tommy Gildseth <tommy.gildseth@usit.uio.no> report
* Go over all OpenSSL return values and make sure we compare themMagnus Hagander2009-01-28
| | | | | | | | 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.
* Fix URL generation in headline. Only tag lexeme will be replaced by space.Teodor Sigaev2009-01-15
| | | | Per http://archives.postgresql.org/pgsql-bugs/2008-12/msg00013.php
* Fix generation of too long headline with ShortWords.Teodor Sigaev2009-01-15
| | | | Per http://archives.postgresql.org/pgsql-hackers/2008-09/msg01088.php
* Insert conditional SPI_push/SPI_pop calls into InputFunctionCall,Tom Lane2009-01-07
| | | | | | | | | | | | | | | | | | | | 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.
* Fix logic in lazy vacuum to decide if it's worth trying to truncate the heap.Heikki Linnakangas2009-01-06
| | | | | | | | 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.
* Fix an oversight in my patch of a couple weeks ago that ensured a snapshotTom Lane2009-01-01
| | | | | | | | | | is available during datatype input in Bind message processing. I put the PopActiveSnapshot() or equivalent just before PortalDefineQuery, which is an unsafe spot for it (in 8.3 and later) because we are carrying a plancache refcount that hasn't yet been assigned to the portal. Any error thrown there would result in leaking the refcount. It's not exactly likely that PopActiveSnapshot would throw an elog, perhaps, but it could happen. Reorder the code and add another comment warning not to do that.
* Fix oversight in ALTER TABLE ENABLE/DISABLE RULE patch: the new enabledTom Lane2008-12-30
| | | | | | | field needs to be included in equalRuleLocks() comparisons, else updates will fail to propagate into relcache entries when they have positive reference count (ie someone is using the relcache entry). Per report from Alex Hunsaker.
* Make heap_update() set newtup->t_tableOid correctly, for consistency withTom Lane2008-12-16
| | | | | | | | | | 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.
* Restore enforce_generic_type_consistency's pre-8.3 behavior of allowing anTom Lane2008-12-14
| | | | | | | actual argument type of ANYARRAY to match an argument declared ANYARRAY, so long as ANYELEMENT etc aren't used. I had overlooked the fact that this is a possible case while fixing bug #3852; but it is possible because pg_statistic contains columns declared ANYARRAY. Per gripe from Corey Horton.
* Fix failure to ensure that a snapshot is available to datatype input functionsTom Lane2008-12-13
| | | | | | | | | | | | | | | | | | | 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.
* Initialize GISTScanOpaque->qual_ok even if there is no conditions.Teodor Sigaev2008-12-04
|
* Fix an oversight in the code that makes transitive-equality deductions fromTom Lane2008-12-01
| | | | | | | | | | | | | | | | | | | | 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.
* Ensure that the contents of a holdable cursor don't depend on out-of-lineTom Lane2008-12-01
| | | | | | | | | | | 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.
* Remove inappropriate memory context switch in shutdown_MultiFuncCall().Tom Lane2008-11-30
| | | | | | | 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.
* Back-patch change to make DISCARD ALL release advisory locks.Tom Lane2008-11-27
| | | | Per discussion.
* Fix crash of xmlconcat(NULL)Peter Eisentraut2008-11-15
| | | | backpatch from 8.4devel
* Prevent synchronous scan during GIN index build, because GIN is optimizedTom Lane2008-11-13
| | | | | | | | | for inserting tuples in increasing TID order. It's not clear whether this fully explains Ivan Sergio Borgonovo's complaint, but simple testing confirms that a scan that doesn't start at block 0 can slow GIN build by a factor of three or four. Backpatch to 8.3. Sync scan didn't exist before that.
* In predtest.c, install a limit on the number of branches we will process inTom Lane2008-11-12
| | | | | | | | | | | | | | | | | 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.)
* Fix off-by-one error in autovacuum shmem struct sizing. This could lead toHeikki Linnakangas2008-11-12
| | | | | | | autovacuum worker sending SIGUSR1 signal to wrong process, per Zou Yong's report. Backpatch to 8.3.
* Get rid of adjust_appendrel_attr_needed(), which has been broken ever sinceTom Lane2008-11-11
| | | | | | | | | | | 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.
* Fix bugs in sqlchar_to_unicode and unicode_to_sqlchar: both were measuringTom Lane2008-11-10
| | | | | | the length of a UTF8 character with pg_mblen (wrong if DB encoding isn't UTF8), and the latter was blithely assuming that a static buffer would somehow revert to all zeroes for each use.
* Translation updatesPeter Eisentraut2008-10-30
|
* Revert previous patch to put the shared memory segment on win32Magnus Hagander2008-10-30
| | | | | | | | in the Global\ namespace, because it caused permission errors on a lot of platforms. We need to come up with something better for 8.4, but for now revert to the pre-8.3.4 behaviour.
* Fix recoveryLastXTime logic so that it actually does what one would expect.Tom Lane2008-10-30
| | | | Per gripe from Kevin Grittner. Backpatch to 8.3, where the bug was introduced.
* Install a more robust solution for the problem of infinite error-processingTom Lane2008-10-27
| | | | | | | | | | | | | 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.
* Better solution to the IN-list issue: instead of having an arbitrary cutoff,Tom Lane2008-10-26
| | | | | | | 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.
* Add a heuristic to transformAExprIn() to make it prefer expanding "x IN (list)"Tom Lane2008-10-25
| | | | | | | | | | | | | 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.
* Fix an old bug in after-trigger handling: AfterTriggerEndQuery took theTom Lane2008-10-25
| | | | | | | | | | | | | | | | | | | | | | | | | 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).
* On second thought, let's not get involved in correcting the feature listPeter Eisentraut2008-10-23
| | | | | in 8.3. The list is quite outdated, and fixing it up would require more effort. Plus, we don't want diverging information schema contents.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-05 15:40:20 +0000