diff options
author | Tom Lane | 2020-03-17 01:05:28 +0000 |
---|---|---|
committer | Tom Lane | 2020-03-17 01:05:52 +0000 |
commit | b4570d33aa045df330bb325ba8a2cbf02266a555 (patch) | |
tree | 4e7ebfee102862d095bfa9eb0dede58a4cca471f /src/include | |
parent | 113758155c11cf993ca0ecee8856e300a2525a30 (diff) |
Avoid holding a directory FD open across assorted SRF calls.
This extends the fixes made in commit 085b6b667 to other SRFs with the
same bug, namely pg_logdir_ls(), pgrowlocks(), pg_timezone_names(),
pg_ls_dir(), and pg_tablespace_databases().
Also adjust various comments and documentation to warn against
expecting to clean up resources during a ValuePerCall SRF's final
call.
Back-patch to all supported branches, since these functions were
all born broken.
Justin Pryzby, with cosmetic tweaks by me
Discussion: https://postgr.es/m/20200308173103.GC1357@telsasoft.com
Diffstat (limited to 'src/include')
-rw-r--r-- | src/include/funcapi.h | 13 |
1 files changed, 12 insertions, 1 deletions
diff --git a/src/include/funcapi.h b/src/include/funcapi.h index f9b75ae3905..b047acdc1a8 100644 --- a/src/include/funcapi.h +++ b/src/include/funcapi.h @@ -234,7 +234,7 @@ extern Datum HeapTupleHeaderGetDatum(HeapTupleHeader tuple); /*---------- * Support for Set Returning Functions (SRFs) * - * The basic API for SRFs looks something like: + * The basic API for SRFs using ValuePerCall mode looks something like this: * * Datum * my_Set_Returning_Function(PG_FUNCTION_ARGS) @@ -271,6 +271,17 @@ extern Datum HeapTupleHeaderGetDatum(HeapTupleHeader tuple); * SRF_RETURN_DONE(funcctx); * } * + * NOTE: there is no guarantee that a SRF using ValuePerCall mode will be + * run to completion; for example, a query with LIMIT might stop short of + * fetching all the rows. Therefore, do not expect that you can do resource + * cleanup just before SRF_RETURN_DONE(). You need not worry about releasing + * memory allocated in multi_call_memory_ctx, but holding file descriptors or + * other non-memory resources open across calls is a bug. SRFs that need + * such resources should not use these macros, but instead populate a + * tuplestore during a single call, and return that using SFRM_Materialize + * mode (see fmgr/README). Alternatively, set up a callback to release + * resources at query shutdown, using RegisterExprContextCallback(). + * *---------- */ |