- 21 8月, 2007 3 次提交
-
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
the core additions. For the moment I diked it out of contrib/Makefile. We should look at turning it into a backward-compatibility package.
-
由 Tom Lane 提交于
Oleg Bartunov and Teodor Sigaev, but I did a lot of editorializing, so anything that's broken is probably my fault. Documentation is nonexistent as yet, but let's land the patch so we can get some portability testing done.
-
- 20 8月, 2007 1 次提交
-
-
由 Peter Eisentraut 提交于
database.
-
- 19 8月, 2007 3 次提交
-
-
由 Andrew Dunstan 提交于
-
由 Bruce Momjian 提交于
< * Allow server log information to be output as INSERT statements > * -Allow server log information to be output as CSV format
-
由 Andrew Dunstan 提交于
redirect_stderr to logging_collector. Original patch from Arul Shaji, subsequently modified by Greg Smith, and then heavily modified by me.
-
- 17 8月, 2007 1 次提交
-
-
由 Bruce Momjian 提交于
> > * Reduce XID consumption of read-only queries > > http://archives.postgresql.org/pgsql-hackers/2007-08/msg00516.php >
-
- 16 8月, 2007 2 次提交
-
-
由 Tom Lane 提交于
are not one of the query's defined result relations, but nonetheless have triggers fired against them while the query is active. This was formerly impossible but can now occur because of my recent patch to fix the firing order for RI triggers. Caching a ResultRelInfo avoids duplicating work by repeatedly opening and closing the same relation, and also allows EXPLAIN ANALYZE to "see" and report on these extra triggers. Use the same mechanism to cache open relations when firing deferred triggers at transaction shutdown; this replaces the former one-element-cache strategy used in that case, and should improve performance a bit when there are deferred triggers on a number of relations.
-
由 Tom Lane 提交于
row within one query: we were firing check triggers before all the updates were done, leading to bogus failures. Fix by making the triggers queued by an RI update go at the end of the outer query's trigger event list, thereby effectively making the processing "breadth-first". This was indeed how it worked pre-8.0, so the bug does not occur in the 7.x branches. Per report from Pavel Stehule.
-
- 15 8月, 2007 4 次提交
-
-
由 Bruce Momjian 提交于
> A third idea would be for a heap scan to check if all rows are visible > and if so set a per-table flag which can be checked by index scans. > Any change to the table would have to clear the flag. To detect > changes during the heap scan a counter could be set at the start and > checked at the end --- if it is the same, the table has not been > modified --- any table change would increment the counter.
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
that still thought they could set HEAP_XMAX_COMMITTED immediately after seeing the other transaction commit. Make them use the same logic as tqual.c does to determine if the hint bit can be set yet.
-
由 Bruce Momjian 提交于
< o Use backend PREPARE/EXECUTE facility for ecpg where possible
-
- 14 8月, 2007 8 次提交
-
-
由 Michael Meskes 提交于
-
由 Michael Meskes 提交于
-
由 Michael Meskes 提交于
-
由 Michael Meskes 提交于
-
由 Michael Meskes 提交于
-
由 Michael Meskes 提交于
- Really prepare statements - Added more regression tests - Added auto-prepare mode - Use '$n' for positional variables, '?' is still possible via ecpg option - Cleaned up the sources a little bit
-
由 Tom Lane 提交于
thorough testing of async-commit mode from the buildfarm. This patch MUST get reverted before 8.3 release!
-
由 Tom Lane 提交于
First, we cannot assume that XLogAsyncCommitFlush guarantees hint bits will be settable, because clog.c's inexact LSN bookkeeping results in windows where a previously flushed transaction is considered unhintable because it shares an LSN slot with a later unflushed transaction. But repair_frag requires XMIN_COMMITTED to be correct so that it can distinguish tuples moved by the current vacuum. Since not being able to set the bit is an uncommon corner case, the most practical way of dealing with it seems to be to abandon shrinking (ie, don't invoke repair_frag) when we find a non-dead tuple whose XMIN_COMMITTED bit couldn't be set. Second, it is possible for the same reason that a RECENTLY_DEAD tuple does not get its XMAX_COMMITTED bit set during scan_heap. But by the time repair_frag examines the tuple it might be possible to set the bit. We therefore must take buffer content lock when calling HeapTupleSatisfiesVacuum a second time, else we can get an Assert failure in SetBufferCommitInfoNeedsSave. This latter bug is latent in existing releases, but I think it cannot actually occur without async commit, since the first HeapTupleSatisfiesVacuum call should always have set the bit. So I'm not going to back-patch it. In passing, reduce the existing "cannot shrink relation" messages from NOTICE to LOG level. The new message must be no higher than LOG if we don't want unpredictable regression test failures, and consistency seems like a good idea. Also arrange that only one such message is reported per VACUUM FULL; in typical scenarios you could get spammed with many such messages, which seems a bit useless.
-
- 13 8月, 2007 3 次提交
-
-
由 Tom Lane 提交于
certain corner cases. Per discussion, the code does what we want, but it really needs to be documented that these functions act differently from regexp_matches.
-
由 Tom Lane 提交于
enlarge the memory chunk in-place when it was feasible to do so. This turns out to not work well at all for scenarios involving repeated cycles of palloc/repalloc/pfree: the eventually freed chunks go into the wrong freelist for the next initial palloc request, and so we consume memory indefinitely. While that could be defended against, the number of cases where the optimization can still be applied drops significantly, and adjusting the initial sizes of StringInfo buffers makes it drop to almost nothing. Seems better to just remove the extra complexity. Per recent discussion and testing.
-
由 Tom Lane 提交于
likewise increase the initial size of the scanner's literal buffer to 1024 (from 128). Instrumentation of the regression tests suggests that this saves a useful amount of repalloc() traffic --- the number of calls occurring during one set of tests drops from about 6900 to about 3900. The old sizes were chosen in the late 90's with an eye to machines much smaller than are common today.
-
- 12 8月, 2007 1 次提交
-
-
由 Tom Lane 提交于
regexp_split_to_table() within a single query. This is only a partial solution, as it turns out that with enough matches per string these functions can also tickle a repalloc() misbehavior. But fixing that is a topic for a separate patch.
-
- 11 8月, 2007 1 次提交
-
-
由 Tom Lane 提交于
that cached compiled patterns will still be there when the function is next called. Clean up looping logic, thereby fixing bug identified by Pavel Stehule. Share setup code between the two functions, add some comments, and avoid risky mixing of int and size_t variables. Clean up the documentation a tad, and accept all the flag characters mentioned in table 9-19 rather than just a subset.
-
- 10 8月, 2007 2 次提交
- 09 8月, 2007 4 次提交
-
-
由 Tom Lane 提交于
Brendan Jurd
-
由 Tom Lane 提交于
constant flow of new connection requests could prevent the postmaster from completing a shutdown or crash restart. This is done by labeling child processes that are "dead ends", that is, we know that they were launched only to tell a client that it can't connect. These processes are managed separately so that they don't confuse us into thinking that we can't advance to the next stage of a shutdown or restart sequence, until the very end where we must wait for them to drain out so we can delete the shmem segment. Per discussion of a misbehavior reported by Keaton Adams. Since this code was baroque already, and my first attempt at fixing the problem made it entirely impenetrable, I took the opportunity to rewrite it in a state-machine style. That eliminates some duplicated code sections and hopefully makes everything a bit clearer.
-
由 Neil Conway 提交于
hash table is allocated in a child context of the agg node's memory context, MemoryContextReset() will reset but *not* delete the child context. Since ExecReScanAgg() proceeds to build a new hash table from scratch (in a new sub-context), this results in leaking the header for the previous memory context. Therefore, use MemoryContextResetAndDeleteChildren() instead. Credit: My colleague Sailesh Krishnamurthy at Truviso for isolating the cause of the leak.
-
由 Tom Lane 提交于
GUC assign hooks are supposed to be made whether doit is true or not.
-
- 07 8月, 2007 1 次提交
-
-
由 Neil Conway 提交于
child memory contexts is indented two spaces to the right of its parent context. This should make it easier to deduce the memory context hierarchy from the output of MemoryContextStats().
-
- 06 8月, 2007 2 次提交
-
-
由 Magnus Hagander 提交于
-
由 Tom Lane 提交于
Per report and partial patch from Chad Wagner.
-
- 05 8月, 2007 4 次提交
-
-
由 Tom Lane 提交于
even if the compiler is not defining __GNUC__. Per report from Dirk Tilger that it is possible for icc to not do that.
-
由 Tom Lane 提交于
check for __INTEL_COMPILER. Per report from Dirk Tilger. Not back-patched since I don't fully trust it yet ...
-
由 Tom Lane 提交于
improve grammar a tad. Per Greg Stark.
-
由 Neil Conway 提交于
expected, exit with an error, rather than complaining about the error on stderr but continuing onward.
-