| Commit message (Collapse) | Author | Age |
... | |
| |
|
|
|
|
|
| |
library code. Tweak progress messages to include elapsed real time,
not only CPU time.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PageGetFreeSpace() was being called while not holding the buffer lock, which
not only could yield a garbage answer, but even if it's the right answer there
might be less space available after we reacquire the buffer lock.
Also repair potential deadlock introduced by my recent performance improvement
in RelationGetBufferForTuple(): it was possible for two heap_updates to try to
lock two buffers in opposite orders. The fix creates a global rule that
buffers of a single heap relation should be locked in decreasing block number
order. Currently, this only applies to heap_update; VACUUM can get away with
ignoring the rule since it holds exclusive lock on the whole relation anyway.
However, if we try to implement a VACUUM that can run in parallel with other
transactions, VACUUM will also have to obey the lock order rule.
|
| |
|
|
|
|
|
|
| |
type never scans a relation directly, it can't be an EPQ target.
Explicitly drop subplan's tuple table to ensure we have no buffer pin
leaks.
|
|
|
|
|
|
|
|
|
|
|
| |
with many NULLs ( inserting of NULL into indexed field cause
ERROR: MemoryContextAlloc: invalid request size)
As a workaround 'vacuum analyze' could be used.
This patch resolves the problem, please upply to 7.1.1 sources and
current cvs tree.
Oleg Bartunov
|
| |
|
|
|
|
| |
dynamic linker change. #include must be before #ifdef test.
|
| |
|
|
|
|
|
|
|
|
| |
trees (mostly my fault). Repair. Also fix long-standing bug in ExecReplace:
after recomputing a concurrently updated tuple, we must recheck constraints.
Make EvalPlanQual leak memory with somewhat less enthusiasm than before,
although plugging leaks fully will require more changes than I care to risk
in a dot-release.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
forced.
|
|
|
|
|
| |
for relations on the nullable side of an OUTER JOIN. For now I think
we'd better refuse such queries.
|
|
|
|
|
|
|
|
|
|
|
| |
when we need to move to a new page; as long as we can insert the new
tuple on the same page as before, we only need LockBuffer and not the
expensive stuff. Also, twiddle bufmgr interfaces to avoid redundant
lseeks in RelationGetBufferForTuple and BufferAlloc. Successive inserts
now require one lseek per page added, rather than one per tuple with
several additional ones at each page boundary as happened before.
Lock contention when multiple backends are inserting in same table
is also greatly reduced.
|
| |
|
|
|
|
|
|
|
|
|
| |
not being consulted anywhere, so remove it and remove the _mdnblocks()
calls that were used to set it. Change smgrextend interface to pass in
the target block number (ie, current file length) --- the caller always
knows this already, having already done smgrnblocks(), so it's silly to
do it over again inside mdextend. Net result: extension of a file now
takes one lseek(SEEK_END) and a write(), not three lseeks and a write.
|
|
|
|
| |
between index order and table order.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint names.
> > A reasonable interpretation of DROP CONSTRAINT "foo" is to drop *all*
> > constraints named "foo" on the target table.
>
> Then it should probably be a good thing to avoid the automatic
> generation of
> duplicate names? I might take a look at that, actually...
>
Christopher Kings-Lynne
|
|
|
|
|
|
|
|
| |
in referencing and referenced columns of an fk constraint
aren't comparable using '=' at constraint definition time
rather than insert/update time.
Stephan Szabo
|
|
|
|
|
|
|
| |
that the original code would consider things like UNIX domain sockets are
regular files.
Gavin Sherry
|
| |
|
|
|
|
|
|
|
|
| |
collected by ANALYZE. Also, add some modest amount of intelligence to
guesses that are used for varlena columns in the absence of any ANALYZE
statistics. The 'width' reported by EXPLAIN is finally something less
than totally bogus for varlena columns ... and, in consequence, hashjoin
estimating should be a little better ...
|
| |
|
|
|
|
|
|
|
|
|
| |
to their children, leading to misbehavior if they had any children that paid
attention to chgParam (most plan node types don't). Append's bug has been
there a long time, but nobody had noticed because it used to be difficult
to create a query where an Append would be used below the top level of a
plan; so there were never any parameters getting passed down. SubqueryScan
is new in 7.1 ... and I'd modeled its behavior on Append :-(
|
|
|
|
|
| |
different directory. This makes dependency tracking work and copes with
compilers that don't suport -c and -o together.
|
| |
|
| |
|
| |
|
|
|
|
| |
set null/default).
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> cronjob:
> NOTICE: RegisterSharedInvalid: SI buffer overflow
> NOTICE: InvalidateSharedInvalid: cache state reset
> I don't understand what these mean. Should I be concerned about them
> and what do they signify?
No real need to worry. Those should've been downgraded to DEBUG-level
messages a release or two back, but nobody bothered...
Tom Lane
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a separate statement (though it can still be invoked as part of VACUUM, too).
pg_statistic redesigned to be more flexible about what statistics are
stored. ANALYZE now collects a list of several of the most common values,
not just one, plus a histogram (not just the min and max values). Random
sampling is used to make the process reasonably fast even on very large
tables. The number of values and histogram bins collected is now
user-settable via an ALTER TABLE command.
There is more still to do; the new stats are not being used everywhere
they could be in the planner. But the remaining changes for this project
should be localized, and the behavior is already better than before.
A not-very-related change is that sorting now makes use of btree comparison
routines if it can find one, rather than invoking '<' twice.
|
|
|
|
| |
going to have any at all.
|
|
|
|
|
| |
running deferred triggers. They are really part of the regular
transaction, and they could take awhile.
|
|
|
|
|
|
|
|
|
| |
routine DetermineLocalTimeZone(). In that routine, be more wary of
broken mktime() implementations than the original code was: don't allow
mktime to change the already-set y/m/d/h/m/s information, and don't
use tm_gmtoff if mktime failed. Possibly this will resolve some of
the complaints we've been hearing from users of Middle Eastern timezones
on RedHat.
|
|
|
|
|
|
|
| |
support two - KOI8-R and KOI8-U (latter is superset of the former if
not to take to the account pseudographics)
Andy Rysin
|
|
|
|
| |
either :-(.
|
|
|
|
|
|
|
|
|
|
| |
give consistent results for all datatypes. Types float4, float8, and
numeric were broken for NaN values; abstime, timestamp, and interval
were broken for INVALID values; timetz was just plain broken (some
possible pairs of values were neither < nor = nor >). Also clean up
text, bpchar, varchar, and bit/varbit to eliminate duplicate code and
thereby reduce the probability of similar inconsistencies arising in
the future.
|
|
|
|
| |
Per bug report from Lieven Van Acker, 5/2/01.
|
|
|
|
|
|
|
| |
This is an extension to the SQL9x standard, but is consistant with usage
of the underlying date_part() function used to implement it.
Example: EXTRACT('YEAR',...)
No impact on regression tests.
|
|
|
|
|
|
| |
join. This is needed to avoid improper evaluation of expressions that
should be nulled out, as in Victor Wagner's bug report of 4/27/01.
Pretty ugly solution, but no time to do anything better for 7.1.1.
|
|
|
|
| |
Patches contributed by Victor Wagner.
|
|
|
|
| |
it's bogus, try building a btree index on the regress tests' abstime_tbl.)
|
|
|
|
|
| |
Without this, it was making some pretty silly decisions about whether an
expensive sub-SELECT should be the inner or outer side of a join...
|
| |
|
|
|
|
| |
complaints about 'Cache reference leak'. Per report from Don Baccus.
|
|
|
|
| |
userids are the same. Per today's pghackers discussion.
|