Re: Remove_temp_files_after_crash and significant recovery/startup time - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Remove_temp_files_after_crash and significant recovery/startup time
Date
Msg-id 4098560.1631309578@sss.pgh.pa.us
Whole thread Raw
In response to Remove_temp_files_after_crash and significant recovery/startup time  ("McCoy, Shawn" <shamccoy@amazon.com>)
List pgsql-hackers
"McCoy, Shawn" <shamccoy@amazon.com> writes:
> I noticed that the new parameter remove_temp_files_after_crash is currently set to a default value of "true" in the
version14 release. It seems this was discussed in this thread [1], and it doesn't look to me like there's been a lot of
stresstesting of this feature. 

Probably not ...

> In our fleet there have been cases where we have seen hundreds of thousands of temp files generated.  I found a case
wherewe helped a customer that had a little over 2.2 million temp files.  Single threaded cleanup of these takes a
significantamount of time and delays recovery. In RDS, we mitigated this by moving the pgsql_tmp directory aside, start
theengine and then separately remove the old temp files. 

TBH, I think the thing to be asking questions about is how come you had so
many temp files in the first place.  Sounds like something is misadjusted
somewhere.

            regards, tom lane



pgsql-hackers by date:

Previous
From: David Zhang
Date:
Subject: Re: ORDER BY pushdowns seem broken in postgres_fdw
Next
From: Tomas Vondra
Date:
Subject: Re: Remove_temp_files_after_crash and significant recovery/startup time