I don't like last minute patches before the final freeze, but I believe that
authorBruce Momjian <bruce@momjian.us>
Sat, 12 Jun 1999 14:05:41 +0000 (14:05 +0000)
committerBruce Momjian <bruce@momjian.us>
Sat, 12 Jun 1999 14:05:41 +0000 (14:05 +0000)
commitf422c8172fb2e70f31e06a189b875f01eb2d3ba8
tree98b9132f00f5c5a1a479f292e841688aef45c9b1
parent8a7b296495cd7d43117ba8b79923111ad7273c1a
I don't like last minute patches before the final freeze, but I believe that
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
src/backend/access/common/heaptuple.c
src/backend/executor/nodeAgg.c
src/backend/utils/misc/trace.c
src/backend/utils/mmgr/portalmem.c
src/include/utils/portal.h
src/include/utils/trace.h