aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils
Commit message (Collapse)AuthorAge
* 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.
* Fix crash in bytea-to-XML mapping when the source value is toasted.Tom Lane2008-10-09
| | | | | Report and fix by Michael McMaster. Some minor code beautification by me, also avoid memory leaks in the special-case paths.
* Fix improper display of fractional seconds in interval valuesTom Lane2008-10-02
| | | | | | when using --enable-integer-datetimes and a non-ISO datestyle. Ron Mayer
* Compare escaped chars case insensitively for ILIKE - per gripe from TGL.Andrew Dunstan2008-09-27
|
* Fix multiple memory leaks in xml_out(). Per report from Matt Magoffin.Tom Lane2008-09-16
|
* Fix caching of foreign-key-checking queries so that when a replan is needed,Tom Lane2008-09-15
| | | | | | | | we regenerate the SQL query text not merely the plan derived from it. This is needed to handle contingencies such as renaming of a table or column used in an FK. Pre-8.3, such cases worked despite the lack of replanning (because the cached plan needn't actually change), so this is a regression. Per bug #4417 from Benjamin Bihler.
* Initialize the minimum frozen Xid in vac_update_datfrozenxid usingAlvaro Herrera2008-09-11
| | | | | | | | | | | | | | | | | | | | 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
* HeapTupleHeaderAdjustCmax made the incorrect assumption that the rawHeikki Linnakangas2008-09-01
| | | | | | | | | command id is the cmin, when it can in fact be a combo cid. That made rows incorrectly invisible to a transaction where a tuple was deleted by multiple aborted subtransactions. Report and patch Karl Schnaitter. Back-patch to 8.3, where combo cids was introduced.
* Fix corner-case bug introduced with HOT: if REINDEX TABLE pg_class (or aTom Lane2008-08-10
| | | | | | | | | | | | REINDEX DATABASE including same) is done before a session has done any other update on pg_class, the pg_class relcache entry was left with an incorrect setting of rd_indexattr, because the indexed-attributes set would be first demanded at a time when we'd forced a partial list of indexes into the pg_class entry, and it would remain cached after that. This could result in incorrect decisions about HOT-update safety later in the same session. In practice, since only pg_class_relname_nsp_index would be missed out, only ALTER TABLE RENAME and ALTER TABLE SET SCHEMA could trigger a problem. Per report and test case from Ondrej Jirman.
* Fix performance bug in write_syslog(): the code to preferentially break theTom Lane2008-07-08
| | | | | | | | | | 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.
* Fix estimate_num_groups() to assume that GROUP BY expressions yielding booleanTom Lane2008-07-07
| | | | | | | | | 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.
* Fix AT TIME ZONE (in all three variants) so that we first try to interpretTom Lane2008-07-07
| | | | | | | | | | | | | | | | 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.)
* Prevent integer overflows during units conversion when displaying a GUCTom Lane2008-07-06
| | | | | | | | | | | | 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.
* Fix transaction-lifespan memory leak in xpath(). Report by Matt Magoffin,Tom Lane2008-07-03
| | | | fix by Kris Jurka.
* Fix unportable (and incorrect anyway) usage of LL constant suffix thatTom Lane2008-06-09
| | | | recently snuck into cash.c. Per report from Edmundo Robles Lopez.
* Fix datetime input functions to correctly detect integer overflow whenTom Lane2008-06-09
| | | | | running on a 64-bit platform ... strtol() will happily return 64-bit output in that case. Per bug #4231 from Geoff Tolley.
* Fix pg_get_ruledef() so that negative numeric constants are parenthesized.Tom Lane2008-06-06
| | | | | | | | | | 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.
* Backpatch Zdenek Kotala's fix to prevent pglz_decompress from stomping onTom Lane2008-05-28
| | | | | | | | memory if the compressed data is corrupt. Backpatch as far as 8.2. The issue exists in older branches too, but given the lack of field reports, it's not clear it's worth any additional effort to adapt the patch to the slightly different code in older branches.
* Explicitly bind gettext() to the UTF8 locale when in use.Magnus Hagander2008-05-27
| | | | | | | | | | This is required on Windows due to the special locale handling for UTF8 that doesn't change the full environment. Fixes crash with translated error messages per bugs 4180 and 4196. Tom Lane
* Fix an old corner-case bug in set_config_option: push_old_value has to beTom Lane2008-05-26
| | | | | | | | | | | | | | called before, not after, calling the assign_hook if any. This is because push_old_value might fail (due to palloc out-of-memory), and in that case there would be no stack entry to tell transaction abort to undo the GUC assignment. Of course the actual assignment to the GUC variable hasn't happened yet --- but the assign_hook might have altered subsidiary state. Without a stack entry we won't call it again to make it undo such actions. So this is necessary to make the world safe for assign_hooks with side effects. Per a discussion a couple weeks ago with Magnus. Back-patch to 8.0. 7.x did not have the problem because it did not have allocatable stacks of GUC values.
* Coercion sanity check in ri_HashCompareOp failed to allow for enums, as perTom Lane2008-05-19
| | | | | example from Rod Taylor. On reflection the correct test here is for any polymorphic type, not specifically ANYARRAY as in the original coding.
* The 8.2 patch that added support for an alias on the target table ofTom Lane2008-05-03
| | | | | UPDATE/DELETE forgot to teach ruleutils.c to display the alias. Per bug #4141 from Mathias Seiler.
* Fix broken compare function for tsquery_ops. Per Tom's report.Teodor Sigaev2008-04-20
| | | | | | | | | | I never understood why initial authors GiST in pgsql choose so stgrange signature for 'same' method: bool *sameFn(Datum a, Datum b, bool* result) instead of simple, logical bool sameFn(Datum a, Datum b) This change will break any existing GiST extension, so we still live with it and will live.
* Fix LOAD_CRIT_INDEX() macro to take out AccessShareLock on the system indexTom Lane2008-04-16
| | | | | | | | | | it is trying to build a relcache entry for. This is an oversight in my 8.2 patch that tried to ensure we always took a lock on a relation before trying to build its relcache entry. The implication is that if someone committed a reindex of a critical system index at about the same time that some other backend were starting up without a valid pg_internal.init file, the second one might PANIC due to not seeing any valid version of the index's pg_class row. Improbable case, but definitely not impossible.
* Fix several datatype input functions that were allowing unused bytes in theirTom Lane2008-04-11
| | | | | | | | | | | | | results to contain uninitialized, unpredictable values. While this was okay as far as the datatypes themselves were concerned, it's a problem for the parser because occurrences of the "same" literal might not be recognized as equal by datumIsEqual (and hence not by equal()). It seems sufficient to fix this in the input functions since the only critical use of equal() is in the parser's comparisons of ORDER BY and DISTINCT expressions. Per a trouble report from Marc Cousin. Patch all the way back. Interestingly, array_in did not have the bug before 8.2, which may explain why the issue went unnoticed for so long.
* Fix tsvector_update_trigger() to be domain-friendly: it needs to allow allTom Lane2008-04-08
| | | | | | the columns it works with to be domains over the expected type, not just exactly the expected type. In passing, fix ts_stat() the same way. Per report from Markus Wollny.
* Revert my bad decision of about a year ago to make PortalDefineQueryTom Lane2008-04-02
| | | | | | | | | | | | | | responsible for copying the query string into the new Portal. Such copying is unnecessary in the common code path through exec_simple_query, and in this case it can be enormously expensive because the string might contain a large number of individual commands; we were copying the entire, long string for each command, resulting in O(N^2) behavior for N commands. (This is the cause of bug #4079.) A second problem with it is that PortalDefineQuery really can't risk error, because if it elog's before having set up the Portal, we will leak the plancache refcount that the caller is trying to hand off to the portal. So go back to the design in which the caller is responsible for making sure everything is copied into the portal if necessary.
* Fix an oversight I made in a cleanup patch over a year ago:Tom Lane2008-04-01
| | | | | | | | | | eval_const_expressions needs to be passed the PlannerInfo ("root") structure, because in some cases we want it to substitute values for Param nodes. (So "constant" is not so constant as all that ...) This mistake partially disabled optimization of unnamed extended-Query statements in 8.3: in particular the LIKE-to-indexscan optimization would never be applied if the LIKE pattern was passed as a parameter, and constraint exclusion depending on a parameter value didn't work either.
* Fix a number of places that were making file-type tests infelicitously.Tom Lane2008-03-31
| | | | | | | | | | | | | | | | | The places that did, eg, (statbuf.st_mode & S_IFMT) == S_IFDIR were correct, but there is no good reason not to use S_ISDIR() instead, especially when that's what the other 90% of our code does. The places that did, eg, (statbuf.st_mode & S_IFDIR) were flat out *wrong* and would fail in various platform-specific ways, eg a symlink could be mistaken for a regular file on most Unixen. The actual impact of this is probably small, since the problem cases seem to always involve symlinks or sockets, which are unlikely to be found in the directories that PG code might be scanning. But it's clearly trouble waiting to happen, so patch all the way back anyway. (There seem to be no occurrences of the mistake in 7.4.)
* Fix various infelicities that have snuck into usage of errdetail() andTom Lane2008-03-24
| | | | | | friends. Avoid double translation of some messages, ensure other messages are exposed for translation (and make them follow the style guidelines), avoid unsafe passing of an unpredictable message text as a format string.
* Add the missing cyrillic "Yo" characters ('e' and 'E' with two dots) to theHeikki Linnakangas2008-03-20
| | | | | | | | | | | | | | | ISO_8859-5 <-> MULE_INTERNAL conversion tables. This was discovered when trying to convert a string containing those characters from ISO_8859-5 to Windows-1251, because we use MULE_INTERNAL/KOI8R as an intermediate encoding between those two. While the missing "Yo" was just an omission in the conversion tables, there are a few other characters like the "Numero" sign ("No" as a single character) that exists in all the other cyrillic encodings (win1251, ISO_8859-5 and cp866), but not in KOI8R. Added comments about that. Patch by Sergey Burladyan. Back-patch to 7.4.
* Fix regexp substring matching (substring(string from pattern)) for the cornerTom Lane2008-03-19
| | | | | | | | | | | | case where there is a match to the pattern overall but the user has specified a parenthesized subexpression and that subexpression hasn't got a match. An example is substring('foo' from 'foo(bar)?'). This should return NULL, since (bar) isn't matched, but it was mistakenly returning the whole-pattern match instead (ie, 'foo'). Per bug #4044 from Rui Martins. This has been broken since the beginning; patch in all supported versions. The old behavior was sufficiently inconsistent that it's impossible to believe anyone is depending on it.
* Fix varstr_cmp's special case for UTF8 encoding on Windows so that stringsTom Lane2008-03-13
| | | | | | | | | | | | that are reported as "equal" by wcscoll() are checked to see if they really are bitwise equal, and are sorted per strcmp() if not. We made this happen a couple of years ago in the regular code path, but it unaccountably got left out of the Windows/UTF8 case (probably brain fade on my part at the time). As in the prior set of changes, affected users may need to reindex indexes on textual columns. Backpatch as far as 8.2, which is the oldest release we are still supporting on Windows.
* Fix heap_page_prune's problem with failing to send cache invalidationTom Lane2008-03-13
| | | | | | | | | | | messages if the calling transaction aborts later on. Collapsing out line pointer redirects is a done deal as soon as we complete the page update, so syscache *must* be notified even if the VACUUM FULL as a whole doesn't complete. To fix, add some functionality to inval.c to allow the pending inval messages to be sent immediately while heap_page_prune is still running. The implementation is a bit chintzy: it will only work in the context of VACUUM FULL. But that's all we need now, and it can always be extended later if needed. Per my trouble report of a week ago.
* Revert changes of CompareTSQ: it affects existing btree indexes.Teodor Sigaev2008-03-09
|
* Fix memory arrangement of tsquery after removing stop words. It causesTeodor Sigaev2008-03-07
| | | | | | | | | | a unused memory holes in tsquery. Per report by Richard Huxton <dev@archonet.com>. It was working well because in fact tsquery->size is not used for any kind of operation except comparing tsqueries. To prevent requirement of renew all stored tsquery optimization in CompareTSQ is removed.
* In PrepareToInvalidateCacheTuple, don't force initialization of catalogTom Lane2008-03-05
| | | | | | | | | | caches that we don't actually need to touch. This saves some trivial number of cycles and avoids certain cases of deadlock when doing concurrent VACUUM FULL on system catalogs. Per report from Gavin Roy. Backpatch to 8.2. In earlier versions, CatalogCacheInitializeCache didn't lock the relation so there's no deadlock risk (though that certainly had plenty of risks of its own).
* Fix unportable usages of tolower(). On signed-char machines, it is necessaryTom Lane2008-03-01
| | | | | | | | | to explicitly cast the output back to char before comparing it to a char value, else we get the wrong result for high-bit-set characters. Found by Rolf Jentsch. Also, fix several places where <ctype.h> functions were being called without casting the argument to unsigned char; this is likewise unportable, but we keep making that mistake :-(. These found by buildfarm member salamander, which I will desperately miss if it ever goes belly-up.
* Disable the undocumented xmlvalidate() function, which was unintentionallyTom Lane2008-03-01
| | | | | | | | | left in the code though it was not meant to be provided. It represents a security hole because unprivileged users could use it to look at (at least the first line of) any file readable by the backend. Fortunately, this is only possible if the backend was built with XML support, so the damage is at least mitigated; and 8.3 probably hasn't propagated into any security-critical uses yet anyway. Per report from Sergey Burladyan.
* Fix several memory leaks when rescanning SRFs. Arrange for an SRF'sNeil Conway2008-02-29
| | | | | | | | | | | | | | | | | | "multi_call_ctx" to be a distinct sub-context of the EState's per-query context, and delete the multi_call_ctx as soon as the SRF finishes execution. This avoids leaking SRF memory until the end of the current query, which is particularly egregious when the SRF is scanned multiple times. This change also fixes a leak of the fields of the AttInMetadata struct in shutdown_MultiFuncCall(). Also fix a leak of the SRF result TupleDesc when rescanning a FunctionScan node. The TupleDesc is allocated in the per-query context for every call to ExecMakeTableFunctionResult(), so we should free it after calling that function. Since the SRF might choose to return a non-expendable TupleDesc, we only free the TupleDesc if it is not being reference-counted. Backpatch to 8.3 and 8.2 stable branches.
* If RelationBuildDesc() fails to open a critical system index, PANIC withTom Lane2008-02-27
| | | | | a relevant error message instead of just dumping core. Odd that nobody reported this before Darren Reed.
* Fix encode(...bytea..., 'escape') so that it converts all high-bit-set byteTom Lane2008-02-26
| | | | | | | | | | | | | | | | | values into \nnn octal escape sequences. When the database encoding is multibyte this is *necessary* to avoid generating invalidly encoded text. Even in a single-byte encoding, the old behavior seems very hazardous --- consider for example what happens if the text is transferred to another database with a different encoding. Decoding would then yield some other bytea value than what was encoded, which is surely undesirable. Per gripe from Hernan Gonzalez. Backpatch to 8.3, but not further. This is a bit of a judgment call, but I make it on these grounds: pre-8.3 we don't really have much encoding safety anyway because of the convert() function family, and we would also have much higher risk of breaking existing apps that may not be expecting this behavior. 8.3 is still new enough that we can probably get away with making this change in the function's behavior.
* Fix datetime input to behave correctly for Feb 29 in years BC.Tom Lane2008-02-25
| | | | | | | | | | | | | | | | | | | Formerly, DecodeDate attempted to verify the day-of-the-month exactly, but it was under the misapprehension that it would know whether we were looking at a BC year or not. In reality this check can't be made until the calling function (eg DecodeDateTime) has processed all the fields. So, split the BC adjustment and validity checks out into a new function ValidateDate that is called only after processing all the fields. In passing, this patch makes DecodeTimeOnly work for BC inputs, which it never did before. (The historical veracity of all this is nonexistent, of course, but if we're going to say we support proleptic Gregorian calendar then we should do it correctly. In any case the unpatched code is broken because it could emit dates that it would then reject on re-inputting.) Per report from Bernd Helmle. Back-patch as far as 8.0; in 7.x we were not using our own calendar support and so this seems a bit too risky to put into 7.4.
* Avoid trying to print a NULL char pointer in --describe-config. On someTom Lane2008-02-23
| | | | platforms this works, but on some it crashes. Zdenek Kotala
* Remove unnecessary opening of other relation in RI_FKey_keyequal_upd_pkTom Lane2008-02-18
| | | | | | | | | | | | | and RI_FKey_keyequal_upd_fk, as well as no-longer-needed calls of ri_BuildQueryKeyFull. Aside from saving a few cycles, this avoids needless deadlock risks when an update is not changing the columns that participate in an RI constraint. Per a gripe from Alexey Nalbat. Back-patch to 8.3. Earlier releases did have a need to open the other relation due to the way in which they retrieved information about the RI constraint, so this problem unfortunately can't easily be improved pre-8.3. Tom Lane and Stephan Szabo
* Avoid misbehavior in foreign key checks when casting to a datatype for whichTom Lane2008-02-07
| | | | | | | | | | | the parser supplies a default typmod that can result in data loss (ie, truncation). Currently that appears to be only CHARACTER and BIT. We can avoid the problem by specifying the type's internal name instead of using SQL-spec syntax. Since the queries generated here are only used internally, there's no need to worry about portability. This problem is new in 8.3; before we just let the parser do whatever it wanted to resolve the operator, but 8.3 is trying to be sure that the semantics of FK checks are consistent. Per report from Harald Fuchs.
* Add pid to the pgident event name on win32.Magnus Hagander2008-01-31
| | | | | | | | | Should fix a problem where two clusters are running under two different service accounts and get colliding names, causing only the first cluster to contain the pgident event description. Per report from Stephen Denne.
* Add a GUC variable "synchronize_seqscans" to allow clients to disable the newTom Lane2008-01-30
| | | | | synchronized-scanning behavior, and make pg_dump disable sync scans so that it will reliably preserve row ordering. Per recent discussions.
* Minor editorial improvements in documentation of session_replication_role;Tom Lane2008-01-27
| | | | | in particular correct the obsolete claim that it can't be changed once any plans have been cached.
* Release any detoasted copies of arrays that are made temporarily inTom Lane2008-01-25
| | | | | | | | | ri_FetchConstraintInfo, to avoid a query-duration memory leak when that routine is called by RI_FKey_keyequal_upd_fk (which isn't executed in a short-lived context). This problem was latent when the routine was added in February, but it didn't become serious until the varvarlena patch made it quite likely that the fields being examined would be "toasted" (ie, have short headers). Per report from Stephen Denne.
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-06 19:29:11 +0000