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)
commit603e153bb8acc27773807a7eacf4e7c3cf8a5a17
tree4d1754201cddb914b0522968e2925aaf9e9baf49
parentbd470ba47e6a99c4667ac8e5e2435d0d33868e2f
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