| Age | Commit message (Collapse) | Author |
|---|
|
fmgr_faddr() in favor of new-style calls. Lots of cleanup of
sloppy casts to use XXXGetDatum and DatumGetXXX ...
|
|
|
|
the src/include tree, so that -I backend is no longer necessary anywhere.
Also, clean up some bit rot in contrib tree.
|
|
key call sites are changed, but most called functions are still oldstyle.
An exception is that the PL managers are updated (so, for example, NULL
handling now behaves as expected in plperl and plpgsql functions).
NOTE initdb is forced due to added column in pg_proc.
|
|
|
|
project I am working on (Recall - a distributed, fault-tolerant,
replicated, storage framework @ http://www.fault-tolerant.org).
Recall is written in C++. I need to include the postgres headers and
there are some problems when including the headers w/C++.
Attached is a patch generated from postgres/src that fixes my problems.
I was hoping to get this into the main source. It's very small (2k) and
3 files are changed: backend/utils/fmgr/fmgr.c,
backend/utils/Gen_fmgrtab.sh.in, and include/access/tupdesc.h.
In C++, you get a multiply defined symbol because the variable
(FmgrInfo *fmgr_pl_finfo) is defined in the header (the patch moves it
to the .c file). The other problem in tupdesc.h is the use of typeid
is a problem in c++ (I renamed it to oidtypeid).
Thanks,
Neal Norwitz
|
|
|
|
syscache and relcache flushes). Relcache entry rebuild now preserves
original tupledesc, rewrite rules, and triggers if possible, so that pointers
to these things remain valid --- if these things change while relcache entry
has positive refcount, we elog(ERROR) to avoid later crash. Arrange for
xact-local rels to be rebuilt when an SI inval message is seen for them,
so that they are updated by CommandCounterIncrement the same as regular rels.
(This is useful because of Hiroshi's recent changes to process our own SI
messages at CommandCounterIncrement time.) This allows simplification of
some routines that previously hacked around the lack of an automatic update.
catcache now keeps its own copy of tupledesc for its relation, rather than
depending on the relcache's copy; this avoids needing to reinitialize catcache
during a cache flush, which saves some cycles and eliminates nasty circularity
problems that occur if a cache flush happens while trying to initialize a
catcache.
Eliminate a number of permanent memory leaks that used to happen during
catcache or relcache flush; not least of which was that catcache never
freed any cached tuples! (Rule parsetree storage is still leaked, however;
will fix that separately.)
Nothing done yet about code that uses tuples retrieved by SearchSysCache
for longer than is safe.
|
|
* Portions Copyright (c) 1996-2000, PostgreSQL, Inc
to all files copyright Regents of Berkeley. Man, that's a lot of files.
|
|
|
|
|
|
|
|
in regression tests.
Jan
|
|
Jan
|
|
Jan
|
|
|
|
|
|
Make all system indexes unique.
Make all cache loads use system indexes.
Rename *rel to *relid in inheritance tables.
Rename cache names to be clearer.
|
|
Fewer calls to nameout.
Better use of RelationGetRelationName.
|
|
pg_dump and interfaces/odbc still need some work.)
|
|
expressions in CREATE TABLE. There is no longer an emasculated expression
syntax for these things; it's full a_expr for constraints, and b_expr
for defaults (unfortunately the fact that NOT NULL is a part of the
column constraint syntax causes a shift/reduce conflict if you try a_expr.
Oh well --- at least parenthesized boolean expressions work now). Also,
stored expression for a column default is not pre-coerced to the column
type; we rely on transformInsertStatement to do that when the default is
actually used. This means "f1 datetime default 'now'" behaves the way
people usually expect it to.
BTW, all the support code is now there to implement ALTER TABLE ADD
CONSTRAINT and ALTER TABLE ADD COLUMN with a default value. I didn't
actually teach ALTER TABLE to call it, but it wouldn't be much work.
|
|
approproate.
|
|
|
|
|
|
|
|
|
|
|
|
this one could be useful for people experiencing out-of-memory crashes while
executing queries which retrieve or use a very large number of tuples.
The problem happens when storage is allocated for functions results used in
a large query, for example:
select upper(name) from big_table;
select big_table.array[1] from big_table;
select count(upper(name)) from big_table;
This patch is a dirty hack that fixes the out-of-memory problem for the most
common cases, like the above ones. It is not the final solution for the
problem but it can work for some people, so I'm posting it.
The patch should be safe because all changes are under #ifdef. Furthermore
the feature can be enabled or disabled at runtime by the `free_tuple_memory'
options in the pg_options file. The option is disabled by default and must
be explicitly enabled at runtime to have any effect.
To enable the patch add the follwing line to Makefile.custom:
CUSTOM_COPT += -DFREE_TUPLE_MEMORY
To enable the option at runtime add the following line to pg_option:
free_tuple_memory=1
Massimo
|
|
|
|
|
|
|
|
real affect now.
|
|
but I think it's OK now...
|
|
can be generated in a buffer and then sent to the frontend in a single
libpq call. This solves problems with NOTICE and ERROR messages generated
in the middle of a data message or COPY OUT operation.
|
|
|
|
|
|
|
|
result, too ... another little bit of speed for SELECT.
|
|
only once per SELECT, not once per tuple. 10% here, 10% there,
pretty soon you're talking about real speedups ...
|
|
seems to have improved speed of routine by 5% or so ...
|
|
but useful speedup.
|
|
so that fetching an attribute value needs only one SearchSysCacheTuple call
instead of two redundant searches. This speeds up a large SELECT by about
ten percent, and probably will help GROUP BY and SELECT DISTINCT too.
|
|
Switch sprintf() to snprintf()
Remove any/all #if 0 -or- #ifdef NOT_USED -or- #ifdef FALSE sections of
code
|
|
enabled PostgreSQL 6.4.
o binary cursor does not work
o pg_dumpall produces incorrect create database statemnt
Tatsuo Ishii
t-ishii@sra.co.jp
|
|
|
|
|
|
just two macros.
|
|
|
|
|
|
|
