| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
when user does another FETCH after reaching end of data, or another
FETCH backwards after reaching start. This is needed because some plan
nodes are not very robust about being called again after they've already
returned NULL; for example, MergeJoin will crash in some states but not
others. While the ideal approach would be for them all to handle this
correctly, it seems foolish to assume that no such bugs would creep in
again once cleaned up. Therefore, the most robust answer is to prevent
the situation from arising at all.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vacuum analyze on pg_type fails if bogus entries remain in pg_operator.
Here is a sample script to reproduce the problem.
drop table t1;
create table t1(i int);
drop function foo(t1,t1);
create function foo(t1,t1) returns bool as 'select true' language 'sql';
create operator = (
leftarg = t1,
rightarg = t1,
commutator = =,
procedure = foo
);
drop table t1;
vacuum analyze;
|
|
|
|
|
|
|
|
|
|
|
| |
only if at least N other backends currently have open transactions. This
is not a great deal of intelligence about whether a delay might be
profitable ... but it beats no intelligence at all. Note that the default
COMMIT_DELAY is still zero --- this new code does nothing unless that
setting is changed.
Also, mark ENABLEFSYNC as a system-wide setting. It's no longer safe to
allow that to be set per-backend, since we may be relying on some other
backend's fsync to have synced the WAL log.
|
|
|
|
|
|
| |
does not lead to a one-second delay, but to an immediate EINVAL failure.
This causes CHECKPOINT to crash with s_lock_stuck much too quickly :-(.
Fix by breaking down the requested wait div/mod 1e6.
|
|
|
|
|
| |
proc_exit(1). Unless you think a system-wide restart is an appropriate
response to bogus PGOPTIONS, that is.
|
|
|
|
|
| |
right. We should MAXALIGN the individual items because we'll
allocate them individually, not as an array.
|
|
|
|
|
|
|
|
|
|
|
| |
> Is there one LOCKMETHODCTL for every backend? I thought there was only
> one of them.
>>
>> You're right, that line is erroneous; it should read
>>
>> size += MAX_LOCK_METHODS * MAXALIGN(sizeof(LOCKMETHODCTL));
>>
>> Not a significant error but it should be changed for clarity ...
|
| |
|
| |
|
|
|
|
| |
Eiji Tokuya" <e-tokuya@Mail.Sankyo-Unyu.co.jp>
|
| |
|
| |
|
| |
|
|
|
|
| |
up the comments later.
|
|
|
|
| |
during WAL recovery. Recovery failure is always serious.
|
|
|
|
| |
microseconds < 100000 should be displayed as, eg, 13.000126, not 13.126.
|
|
|
|
|
|
|
| |
in Turkish locale. Keywords are now checked under pure ASCII case-folding
rules ('A'-'Z'->'a'-'z' and nothing else). However, once a word is
determined not to be a keyword, it will be case-folded under the current
locale, same as before. See pghackers discussion 20-Feb-01.
|
|
|
|
| |
in multi-byte build.
|
|
|
|
| |
or library directories on the command line.
|
|
|
|
| |
so that we don't reject overlength names unnecessarily.
|
|
|
|
| |
syntax. Fix the RESULT_OID case, which never worked. Add documentation.
|
|
|
|
| |
the ones specified by SQL.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
waste of cycles on single-CPU machines, and of dubious utility on multi-CPU
machines too.
Tweak s_lock_stuck so that caller can specify timeout interval, and
increase interval before declaring stuck spinlock for buffer locks and XLOG
locks.
On systems that have fdatasync(), use that rather than fsync() to sync WAL
log writes. Ensure that WAL file is entirely allocated during XLogFileInit.
|
|
|
|
|
|
| |
either wrong or unnecessary in most cases, and on systems where setting
status takes a kernel call, the overhead of setting status three times
per command rather than two is annoying.
|
|
|
|
| |
FileWrite, FileSeek.
|
|
|
|
| |
with encoding other than SQL_ASCII. Per recent discussion in pghackers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. If there is exactly one pg_operator entry of the right name and oprkind,
oper() and related routines would return that entry whether its input type
had anything to do with the request or not. This is just premature
optimization: we shouldn't return the single candidate until after we verify
that it really is a valid candidate, ie, is at least coercion-compatible
with the given types.
2. oper() and related routines only promise a coercion-compatible result.
Unfortunately, there were quite a few callers that assumed the returned
operator is binary-compatible with the given datatype; they would proceed
to call it without making any datatype coercions. These callers include
sorting, grouping, aggregation, and VACUUM ANALYZE. In general I think
it is appropriate for these callers to require an exact or binary-compatible
match, so I've added a new routine compatible_oper() that only succeeds if
it can find an operator that doesn't require any run-time conversions.
Callers now call oper() or compatible_oper() depending on whether they are
prepared to deal with type conversion or not.
The upshot of these bugs is revealed by the following silliness in PL/Tcl's
selftest: it creates an operator @< on int4, and then tries to use it to
sort a char(N) column. The system would let it do that :-( (and evidently
has done so since 6.3 :-( :-(). The result in this case was just a silly
sort order, but the reverse combination would've provoked coredump from
trying to dereference integers. With this fix you get more reasonable
behavior:
pltcl_test=# select * from T_pkey1 order by key1, key2 using @<;
ERROR: Unable to identify an operator '@<' for types 'bpchar' and 'bpchar'
You will have to retype this query using an explicit cast
|
|
|
|
|
| |
relations. It's not very bright, but at least it now knows that
A LEFT JOIN B must produce at least as many rows as are in A ...
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
compressed storage works perfectly well. Might as well have a coherent
strategy for applying it, rather than the haphazard store-what-you-get
approach that was in the code before. The strategy I've set up here is
to attempt compression of any compressible index value exceeding
BLCKSZ/16, or about 500 bytes by default.
|
|
|
|
|
|
|
| |
the old ones were not small enough to ensure r-tree and gist indexes would
get picked when available. These numbers are totally bogus anyway, but
in the absence of any real estimation technique, we'd like to select
indexes when available ...
|
| |
|
|
|
|
| |
Eiji Tokuya" <e-tokuya@Mail.Sankyo-Unyu.co.jp>
|
|
|
|
|
|
|
|
|
|
| |
such as
SELECT f1 FROM foo UNION SELECT ... ORDER BY upper(f1)
to draw
'ORDER BY on a UNION/INTERSECT/EXCEPT result must be on one of the result columns'
rather than the uninformative 'f1 not found' we were producing before.
Eventually this should actually work, but that looks much too hard to try
to implement in late beta...
|
|
|
|
| |
specifies redundant UNIQUE conditions.
|
|
|
|
|
|
|
|
|
| |
clause with an alias is a <subquery> and therefore hides table references
appearing within it, according to the spec. This is the same as the
preliminary patch I posted to pgsql-patches yesterday, plus some really
grotty code in ruleutils.c to reverse-list a query tree with the correct
alias name depending on context. I'd rather not have done that, but unless
we want to force another initdb for 7.1, there's no other way for now.
|
|
|
|
|
| |
GetFreeXLBuffer(): use Insert->LgwrResult instead of private LgwrResult
copy if it's more fresh (attempt to avoid acquiring info_lck/lgwr_lck).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as previously discussed.
It makes AIX and IRIX not use DST for dates before 1970.
The following expected files need to be removed from the regression tests,
they contain wrong results and are not needed any more.
src/test/regress/expected/horology-1947-PDT.out
src/test/regress/expected/tinterval-1947-PDT.out
src/test/regress/expected/abstime-1947-PDT.out
Zeugswetter Andreas
|
| |
|
| |
|
|
|
|
|
|
| |
definitions from K&R to ANSI C style, and fix broken assumption that
int and long are the same datatype. This repairs problems observed
on Alpha with regexps having between 32 and 63 states.
|
| |
|
|
|
|
|
|
|
|
|
| |
two transactions create the same table name concurrently, the one that
fails will complain about unique index pg_class_relname_index, rather than
about pg_type_typname_index which'll confuse most people. Free side
benefit: pg_class.reltype is correctly linked to the pg_type entry now.
It's been zero in all but the preloaded pg_class entries since who knows
when.
|
| |
|
| |
|