> the DTK_MICROSEC case is just like the DTK_MILLISEC case.
> I think this is wrong and it ought to look like
> fsec = rint(fsec * 1000000) / 1000000;
> no?
Tom Lane.
"HAS_LONG_LONG" is defined based on the assumption that
strtol() would return ERANGE if a platform does not support
64-bit integers. In current PostgreSQL 6.5 (and 6.4.2)
distribution, "HAS_LONG_LONG" is defined only if platform
is "alpha". (See include/port/alpha.h) I think the int4
range check should apply to linux_alpha as well. (I have
not tested yet but I guess this might be applicable to
newer Linux/i386 distributions which includes new GCC which
implements long int as 64-bit int.)
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
a non-leading % would be put into the >=/<= patterns. Also, repair
longstanding confusion about whether %% means a literal %%. The SQL92
doesn't say any such thing, and textlike() knows that, but gram.y didn't.
the gettimeofday doesn't compile under Linux with glibc2 because
the DST_NONE constant is no more defined. It seems that this code
(written by me) has always be wrong but for some reason working.
From: Massimo Dal Zotto <dz@cs.unitn.it>
The
offending code
has been removed, the action is now always dependent :-)
I suggest the following patch, to finally make trigger regression happy
again:
<<refint1.patch>>
After that you can remove the following from TODO:
Remove ERROR: check_primary_key: even number of arguments should be
specified
Trigger regression test fails
Andreas
-d4 now prints compressed trees from nodeToString()
-d5 prints pretty trees via nodeDisplay()
new pg_options: pretty_plan, pretty_parse, pretty_rewritten
Jan
arrayfuncs.patch fixes a small bug in my previous patches for
arrays
array-regress.patch adds _bpchar and _varchar to regression tests
--
Massimo Dal Zotto
been applied. The patches are in the .tar.gz attachment at the end:
varchar-array.patch this patch adds support for arrays of bpchar() and
varchar(), which where always missing from postgres.
These datatypes can be used to replace the _char4,
_char8, etc., which were dropped some time ago.
block-size.patch this patch fixes many errors in the parser and other
program which happen with very large query statements
(> 8K) when using a page size larger than 8192.
This patch is needed if you want to submit queries
larger than 8K. Postgres supports tuples up to 32K
but you can't insert them because you can't submit
queries larger than 8K. My patch fixes this problem.
The patch also replaces all the occurrences of `8192'
and `1<<13' in the sources with the proper constants
defined in include files. You should now never find
8192 hardwired in C code, just to make code clearer.
--
Massimo Dal Zotto
to save a little bit of backend startup time. This way, the first
backend started after a VACUUM will rebuild the init file with up-to-date
statistics for the critical system indexes.
