Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-hackers@postgresql.org, Fabien COELHO <coelho@cri.ensmp.fr>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
David Steele <david@pgmasters.net>,
"Bossart,
Nathan" <bossartn@amazon.com>,
Thomas Munro <thomas.munro@gmail.com>
Date: 2020-03-08T20:30:44Z
Lists: pgsql-hackers
I wrote: > I've just finished scanning the source code and concluding that all > of these functions are similarly broken: > pg_ls_dir > pg_ls_dir_files > pg_tablespace_databases > pg_logdir_ls_internal > pg_timezone_names > pgrowlocks BTW, another thing I noticed while looking around is that some of the functions using SRF_RETURN_DONE() think they should clean up memory beforehand. This is a waste of code/cycles, as long as the memory was properly allocated in funcctx->multi_call_memory_ctx, because funcapi.c takes care of deleting that context. We should probably document that *any* manual cleanup before SRF_RETURN_DONE() is an antipattern. If you have to have cleanup, it needs to be done via RegisterExprContextCallback instead. regards, tom lane
Commits
-
Teach pg_ls_dir_files() to ignore ENOENT failures from stat().
- ee40e8975e2c 12.3 landed
- 83f7761d84e6 10.13 landed
- 82e801852274 13.0 landed
- 5b22ff764b0f 11.8 landed
-
Remove useless pfree()s at the ends of various ValuePerCall SRFs.
- 41b45576d532 13.0 landed
-
Avoid holding a directory FD open across assorted SRF calls.
- cd6a0518794d 9.6.18 landed
- 5e4a0b7194b9 10.13 landed
- 819d5525744b 11.8 landed
- 2a89455aade3 12.3 landed
- b4570d33aa04 13.0 landed
- da254148f4de 9.5.22 landed
-
Document pg_ls_*dir hiding of directories and special files
- 8b6d94cf6c83 13.0 cited
-
Avoid holding a directory FD open across pg_ls_dir_files() calls.
- 05283dd5b579 10.13 landed
- 63b51dfec18e 11.8 landed
- 3c8864fc1c54 12.3 landed
- 085b6b6679e7 13.0 landed
-
Adjust nodeFunctionscan.c to reset transient memory context between calls
- e4186762ffaa 7.3.1 cited