aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeHashjoin.c
diff options
context:
space:
mode:
authorDavid Rowley <drowley@postgresql.org>2022-07-07 08:14:00 +1200
committerDavid Rowley <drowley@postgresql.org>2022-07-07 08:14:00 +1200
commit0229106afab93e9868e758f4b555daafcfac4b75 (patch)
tree7f9a8b0db2c5f583c996d898637844609e3d871d /src/backend/executor/nodeHashjoin.c
parent2d7ead85267cc0a41ea4e94ee0ac144d5214d353 (diff)
downloadpostgresql-0229106afab93e9868e758f4b555daafcfac4b75.tar.gz
postgresql-0229106afab93e9868e758f4b555daafcfac4b75.zip
Overload index_form_tuple to allow the memory context to be supplied
40af10b57 changed things so we make use of a generation memory context for storing tuples to be sorted by tuplesort.c. That change does not play nicely with the changes made in 9f03ca915 (back in 2014). That commit changed things so that index_form_tuple() is called while switched into the tuplestore's tuplecontext. In order to fetch the tuple from the index, index_form_tuple() must do various memory allocations which are unrelated to the storage of the final returned tuple. Although all of these allocations are pfree'd, the fact that we now use a generation context means that the memory for these pfree'd allocations won't be used again by any other allocation due to generation.c's lack of freelists. This could result in sorts used for building indexes exceeding maintenance_work_mem by a very large amount. Here we fix it so we no longer allocate anything apart from the tuple itself into the generation context by adding a new version of index_form_tuple named index_form_tuple_context, which can be called to specify the MemoryContext to allocate the tuple into. Discussion: https://postgr.es/m/CAApHDvrHQkiFRHiGiAS-LMOvJN-eK-s762=tVzBz8ZqUea-a_A@mail.gmail.com Backpatch-through: 15, where 40af10b57 was added.
Diffstat (limited to 'src/backend/executor/nodeHashjoin.c')
0 files changed, 0 insertions, 0 deletions