- 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.
-
- 07 3月, 2008 4 次提交
-
-
由 Tom Lane 提交于
TopMemoryContext, rather than scattered through executor per-query contexts. This poses no danger of memory leak since the ResourceOwner mechanism guarantees release of no-longer-needed items. It is needed because the per-query context might already be released by the time we try to clean up the hash scan list. Report by ykhuang, diagnosis by Heikki. Back-patch to 8.0, where the ResourceOwner-based cleanup was introduced. The given test case does not fail before 8.2, probably because we rearranged transaction abort processing somehow; but this coding is undoubtedly risky so I'll patch 8.0 and 8.1 anyway.
-
由 Teodor Sigaev 提交于
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.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
Back patch to 8.3.X.
-
- 06 3月, 2008 5 次提交
-
-
由 Bruce Momjian 提交于
just reference them from the localization doc section. Backpatch to 8.3.X.
-
由 Alvaro Herrera 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
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).
-
由 Bruce Momjian 提交于
checkpoint timeout can incrase the time needed for crash recovery, per suggestion from Simon.
-
- 05 3月, 2008 2 次提交
-
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
temporary table; we can't support that because there's no way to clean up the source backend's internal state if the eventual COMMIT PREPARED is done by another backend. This was checked correctly in 8.1 but I broke it in 8.2 :-(. Patch by Heikki Linnakangas, original trouble report by John Smith.
-
- 04 3月, 2008 1 次提交
-
-
由 Magnus Hagander 提交于
Dave Page
-