- 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 7 次提交
-
-
由 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.
-
由 Tom Lane 提交于
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.
-
- 13 3月, 2008 2 次提交
-
-
由 Tom Lane 提交于
(probably NULL) before exiting. Up to now it's just left the variable as it set it, which means that after we're done processing the current client message, ActiveSnapshot is probably pointing at garbage (because this function is typically run in MessageContext which will get reset). There doesn't seem to have been any code path in which that mattered before 8.3, but now the plancache module might try to use the stale value if the next client message is a Bind for a prepared statement that is in need of replanning. Per report from Alex Hunsaker.
-
由 Tom Lane 提交于
pg_listener modifications commanded by LISTEN and UNLISTEN until the end of the current transaction. This allows us to hold the ExclusiveLock on pg_listener until after commit, with no greater risk of deadlock than there was before. Aside from fixing the race condition, this gets rid of a truly ugly kludge that was there before, namely having to ignore HeapTupleBeingUpdated failures during NOTIFY. There is a small potential incompatibility, which is that if a transaction issues LISTEN or UNLISTEN and then looks into pg_listener before committing, it won't see any resulting row insertion or deletion, where before it would have. It seems unlikely that anyone would be depending on that, though. This patch also disallows LISTEN and UNLISTEN inside a prepared transaction. That case had some pretty undesirable properties already, such as possibly allowing pg_listener entries to be made for PIDs no longer present, so disallowing it seems like a better idea than trying to maintain the behavior.
-
- 12 3月, 2008 1 次提交
-
-
由 Bruce Momjian 提交于
+ Setting <varname>statement_timeout</> in + <filename>postgresql.conf</> is not recommended because it + affects all sessions. Backpatch to 8.3.X.
-
- 11 3月, 2008 3 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
because it affects all sessions, including autovacuum.
-
由 Tom Lane 提交于
This prevents compiler optimizations that assume overflow won't occur, which breaks numerous overflow tests that we need to have working. It is known that gcc 4.3 causes problems and possible that 4.1 does. Per my proposal of some time ago and a recent report from Kris Jurka. Backpatch as far as 8.0, which is as far as the patch conveniently goes. 7.x was pretty short of overflow tests anyway, so it may not matter there, even assuming that anyone cares whether 7.x builds on recent gcc.
-
- 09 3月, 2008 2 次提交
-
-
由 Teodor Sigaev 提交于
-
由 Tom Lane 提交于
it accumulates the set of changes to be made and then applies them. It had to accumulate the set of changes anyway to prepare a WAL record for the pruning action, so this isn't an enormous change; the only new complexity is to not doubly mark tuples that are visited twice in the scan. The main advantage is that we can substantially reduce the scope of the critical section in which the changes are applied, thus avoiding PANIC in foreseeable cases like running out of memory in inval.c. A nice secondary advantage is that it is now far clearer that WAL replay will actually do the same thing that the original pruning did. This commit doesn't do anything about the open problem that CacheInvalidateHeapTuple doesn't have the right semantics for a CTID change caused by collapsing out a redirect pointer. But whatever we do about that, it'll be a good idea to not do it inside a critical section.
-