- 18 4月, 2008 1 次提交
-
-
由 Tom Lane 提交于
we had several code paths where a physical tlist could be used for the input to a Sort node, which is a dumb idea because any unneeded table columns will increase the volume of data the sort has to push around. (Unfortunately the easy-looking fix of calling disuse_physical_tlist during make_sort_xxx doesn't work because in most cases we're already committed to the current input tlist --- it's been marked with sort column numbers, or we've built grouping column numbers using it, etc. The tlist has to be selected properly at the calling level before we start constructing sort-col information. This is easy enough to do, we were just failing to take the point into consideration.) Back-patch to 8.3. I believe the problem probably exists clear back to 7.4 when the physical tlist optimization was added, but I'm afraid to back-patch further than 8.3 without a great deal more study than I want to put into it. The code in this area has drifted a lot over time. The real-world importance of these code paths is uncertain anyway --- I think in many cases we'd probably prefer hash-based methods.
-
- 17 4月, 2008 2 次提交
-
-
由 Tom Lane 提交于
corrupted. (Neither is very important if SIGTERM is used to shut down the whole database cluster together, but there's a problem if someone tries to SIGTERM individual backends.) To do this, introduce new infrastructure macros PG_ENSURE_ERROR_CLEANUP/PG_END_ENSURE_ERROR_CLEANUP that take care of transiently pushing an on_shmem_exit cleanup hook. Also use this method for createdb cleanup --- that wasn't a shared-memory-corruption problem, but SIGTERM abort of createdb could leave orphaned files lying around. Backpatch as far as 8.2. The shmem corruption cases don't exist in 8.1, and the createdb usage doesn't seem important enough to risk backpatching further.
-
由 Tom Lane 提交于
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.
-
- 16 4月, 2008 2 次提交
-
-
由 Andrew Dunstan 提交于
-
由 Andrew Dunstan 提交于
-
- 12 4月, 2008 2 次提交
-
-
由 Tom Lane 提交于
pgwin32_safestat remains to be determined, but in any case the current code is not tolerable.
-
由 Tom Lane 提交于
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.
-
- 11 4月, 2008 1 次提交
-
-
由 Magnus Hagander 提交于
on win32, because the stat() function in the runtime cannot be trusted to always update the st_size field. Per report and research by Sergey Zubkovsky.
-
- 10 4月, 2008 1 次提交
-
-
由 Michael Meskes 提交于
-
- 09 4月, 2008 1 次提交
-
-
由 Tom Lane 提交于
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.
-
- 05 4月, 2008 1 次提交
-
-
由 Tom Lane 提交于
currently support this because we must be able to build Vars referencing join columns, and varattno is only 16 bits wide. Perhaps this should be improved in future, but considering that it never came up before, I'm not sure the problem is worth much effort. Per bug #4070 from Marcello Ceschia. The problem seems largely academic in 8.0 and 7.4, because they have (different) O(N^2) performance issues with such wide joins, but back-patch all the way anyway.
-
- 04 4月, 2008 1 次提交
-
-
由 Tom Lane 提交于
classed all as "dead"; also get it to count DEAD item pointers as dead rows, instead of ignoring them as before. Also improve matters so that tuples previously inserted or deleted by our own transaction are handled nicely: the stats collector's live-tuple and dead-tuple counts will end up correct after our transaction ends, regardless of whether we end in commit or abort. While there's more work that could be done to improve the counting of in-doubt tuples in both VACUUM and ANALYZE, this commit is enough to alleviate some known bad behaviors in 8.3; and the other stuff that's been discussed seems like research projects anyway. Pavan Deolasee and Tom Lane
-
- 03 4月, 2008 2 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
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.
-
- 01 4月, 2008 2 次提交
-
-
由 Tom Lane 提交于
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.
-
由 Tom Lane 提交于
Add some regression tests for plausible failures in this area.
-
- 31 3月, 2008 1 次提交
-
-
由 Tom Lane 提交于
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.)
-
- 29 3月, 2008 1 次提交
-
-
由 Tom Lane 提交于
Whatever we do about that, this isn't the path to the solution.
-
- 28 3月, 2008 1 次提交
-
-
由 Tom Lane 提交于
the query result must be exactly one row (since we don't do this when there's any GROUP BY). Therefore any ORDER BY or DISTINCT attached to the query is useless and can be dropped. Aside from saving useless cycles, this protects us against problems with matching the hacked-up tlist entries to sort clauses, as seen in a bug report from Taiki Yamaguchi. We might need to work harder if we ever try to optimize grouped queries with this approach, but this solution will do for now.
-
- 26 3月, 2008 2 次提交
-
-
由 Magnus Hagander 提交于
While at it, change the order of the documented options to be alphabetically again.
-
由 Tom Lane 提交于
a NULL value. Per bug #4058.
-
- 25 3月, 2008 3 次提交
-
-
由 Michael Meskes 提交于
-
由 Tom Lane 提交于
knowledge up through any joins it participates in. We were doing that already in some special cases but not in the general case. Also, defend against zero row estimates for the input relations in cost_mergejoin --- this fix may have eliminated the only scenario in which that can happen, but be safe. Per report from Alex Solovey.
-
由 Tom Lane 提交于
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.
-
- 22 3月, 2008 1 次提交
-
-
由 Michael Meskes 提交于
-
- 21 3月, 2008 2 次提交
-
-
由 Michael Meskes 提交于
Bumped library version to 6.1.
-
由 Michael Meskes 提交于
Bumped precompiler patchlevel.
-
- 20 3月, 2008 1 次提交
-
-
由 Heikki Linnakangas 提交于
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.
-
- 19 3月, 2008 3 次提交
-
-
由 Tom Lane 提交于
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.
-
由 Magnus Hagander 提交于
-
由 Magnus Hagander 提交于
on developer.postgresql.org is going away.
-
- 15 3月, 2008 3 次提交
-
-
由 Tom Lane 提交于
This accidentally failed to fail before 8.3, because the context we were switching back to was long-lived anyway; but it sure looks risky as can be now. Well spotted by Pavan Deolasee.
-
由 Alvaro Herrera 提交于
-
由 Alvaro Herrera 提交于
job (i.e. to prevent Xid wraparound problems.) Bug reported by ITAGAKI Takahiro in 20080314103837.63D3.52131E4D@oss.ntt.co.jp, though I didn't use his patch.
-
- 14 3月, 2008 6 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Marc G. Fournier 提交于
update configure for 8.3.1 prior to tag
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
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.
-