Re: Remove_temp_files_after_crash and significant recovery/startup time

On 9/10/21 10:58 PM, McCoy, Shawn wrote:
> I noticed that the new parameter remove_temp_files_after_crash is
> currently set to a default value of "true" in the version 14 release. It
> seems this was discussed in this thread [1], and it doesn't look to me
> like there's been a lot of stress testing of this feature.
>

Not sure what could we learn from a stress test? IMHO it's fairly
natural that if there are many temporary files and/or if deleting a file
is expensive on a given filesystem, the cleanup may take time.

> In our fleet there have been cases where we have seen hundreds of
> thousands of temp files generated.  I found a case where we helped a
> customer that had a little over 2.2 million temp files.  Single threaded
> cleanup of these takes a significant amount of time and delays recovery.
> In RDS, we mitigated this by moving the pgsql_tmp directory aside, start
> the engine and then separately remove the old temp files.
>
> After noticing the current plans to default this GUC to "on" in v14,
> just thought I'd raise the question of whether this should get a little
> more discussion or testing with higher numbers of temp files?
>

I doubt we can lean anything new from such testing.

Of course, we can discuss the default for the GUC. I see it as a trade
off between risk of running out of disk space and increased recovery
time, and perhaps the decision to prioritize lower risk of running out
of disk space was not the right one ...

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company