- 15 3月, 2008 1 次提交
-
-
由 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 4 次提交
-
-
由 Magnus Hagander 提交于
Dave Page
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 02 3月, 2008 3 次提交
-
-
由 Michael Meskes 提交于
-
由 Tom Lane 提交于
of "VET" accordingly. Per bug #3997 from Aaron Mizrachi.
-
由 Tom Lane 提交于
"struct varlena" would be at least word-aligned. Per buildfarm results from gypsy_moth. I did a little bit of trawling for other instances of this coding pattern, and didn't find any; but if we turn up any more of them I think we'd better revert the "char [4]" patch and find another way of making tuptoaster.c alignment-safe.
-
- 01 3月, 2008 4 次提交
-
-
由 Tom Lane 提交于
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.
-
由 Tom Lane 提交于
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.
-
由 Andrew Dunstan 提交于
-
由 Tom Lane 提交于
is also licensed to put a local variable declared that way at an unaligned address. Which will not work if the variable is then manipulated with SET_VARSIZE or other macros that assume alignment. So the previous patch is not an unalloyed good, but on balance I think it's still a win, since we have very few places that do that sort of thing. Fix the one place in tuptoaster.c that does it. Per buildfarm results from gypsy_moth (I'm a bit surprised that only one machine showed a failure).
-
- 29 2月, 2008 2 次提交
-
-
由 Magnus Hagander 提交于
by explicitly adding back the user to the DACL of the new process. This fixes the failure case when executing as the Administrator user, which had no permissions left at all after we dropped the Administrators group. Dave Page with some modifications from me
-
由 Neil Conway 提交于
"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.
-