| Age | Commit message (Collapse) | Author |
|---|
|
WARNING. Fix German FAQ mention about warning.
|
|
insensitive to the order of arguments. Per pghackers discussion 12/10/00.
|
|
> Date: Thu, 14 Dec 2000 12:44:47 +0100 (CET)
> From: Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
> To: pgsql-bugs@postgresql.org
> Subject: [BUGS] to_char() causes backend to close connection
>
> Hi, this query gives different strange results:
>
> select to_char(now()::abstime,'YYMMDDHH24MI');
>
> I get e.g. a "backend closed the channel unexpectedly..." error with
> successful or failed resetting attempt (indeterministic)
Again thanks Kovacs, you found really designing bug, that appear
if anyone write bad format template to "number" version of to_char()
(as you with 'DD').
Karel
|
|
if we set autocommit off and issued COMMIT (or ROLLBACK) on a connection
new transaction is not started
Max Khon
|
|
(intermediate .o file gets deleted and rebuild on next make invocation).
|
|
|
|
backend crash.
|
|
|
|
Trying to connect to template0 left a global referenced buffer
because the scan of pg_database wasn't ended properly before
elog(FATAL).
Jan
|
|
comparison does not consider paths different when they differ only in
uninteresting aspects of sort order. (We had a special case of this
consideration for indexscans already, but generalize it to apply to
ordered join paths too.) Be stricter about what is a canonical pathkey
to allow faster pathkey comparison. Cache canonical pathkeys and
dispersion stats for left and right sides of a RestrictInfo's clause,
to avoid repeated computation. Total speedup will depend on number of
tables in a query, but I see about 4x speedup of planning phase for
a sample seven-table query.
|
|
|
|
OIDs rather than names. Aside from being simpler and faster, this way
doesn't blow up in the face of 'create temp table foo () inherits (foo)'.
Which is a rather odd thing to do, but it seems some people want to.
|
|
output first outer tuple before advancing...
|
|
avoid repeated evaluations in cost_qual_eval(). This turns out to save
a useful fraction of planning time. No change to external representation
of RestrictInfo --- although that node type doesn't appear in stored
rules anyway.
|
|
|
|
|
|
|
|
not match.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
all forms of foreign keys be exposed to SQLForeignKeys. This patch is in
addition to the ones I mailed yesterday (forget had I changed that as
well....)
Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio
|
|
return foreign key information based on the pg_trigger system table. I
have tested the patch with (what I believe) is all possible
primary/foreign key combinations -- however I may have missed some, so if
anyone feels like taking the patch for a test drive, here are some useful
links:
Michael Fork
|
|
|
|
is the only diff not accounted for by fmgr rewrite...
|
|
|
|
Thanks Chih-Chang Hsieh <cch@cc.kmu.edu.tw> for finding the bug.
|
|
varlena type. (I did not force initdb, but you won't see the fix
unless you do one.) Also, make sure all index support operators and
functions are careful not to leak memory for toasted inputs; I had
missed some hash and rtree support ops on this point before.
|
|
mostly just on the WAL logfile nowadays. But if people want to disable
fsync for performance, why should we say no?
|
|
|
|
value greater than one. The behavior this sought to disallow doesn't
seem any less confusing than the other behaviors of cached sequences.
Improve wording of some error messages, too.
Update documentation accordingly. Also add an explanation that
aborted transactions do not roll back their nextval() calls; this
seems to be a FAQ, so it ought to be mentioned here...
|
|
|
|
|
|
or return type.
|
|
or return type.
|
|
or return type.
|
|
length is less than original string length.
|
|
|
|
|
|
As I read it, the spec requires a non-null result in some cases where
one of the inputs is NULL: specifically, if the other endpoint of that
interval is between the endpoints of the other interval, then the result
is known TRUE despite the missing endpoint. The spec could've been a
lot simpler if they did not intend this behavior.
I did not force an initdb for this change, but if you don't do one you'll
still see the old strict-function behavior.
|
|
if the transaction has already been committed ?
|
|
|
|
|
|
transformForUpdate does: it should recurse into subqueries.
|
|
It could be recursing into a sub-query where there was already a FOR
UPDATE clause.
|
|
work where we can (given that the executor only handles it at top level)
and generate an error where we can't. Note that while the parser has
been allowing views to say SELECT FOR UPDATE for a few weeks now, that
hasn't actually worked until just now.
|
