--- title: All Your GUCs in a Row: remove_temp_files_after_crash description: The PostgreSQL parameter remove_temp_files_after_crash protects disk space by deleting orphaned temporary files after a backend crash, and should stay on in... canonical: https://daily.dev/posts/all-your-gucs-in-a-row-remove-temp-files-after-crash-v1rldwbpj twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: All Your GUCs in a Row: remove_temp_files_after_crash | daily.dev og:description: The PostgreSQL parameter remove_temp_files_after_crash protects disk space by deleting orphaned temporary files after a backend crash, and should stay on in... og:url: https://daily.dev/posts/all-your-gucs-in-a-row-remove-temp-files-after-crash-v1rldwbpj og:image: https://api.daily.dev/og/posts/V1rLdWbpJ.png og:image:alt: All Your GUCs in a Row: remove_temp_files_after_crash og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # All Your GUCs in a Row: remove_temp_files_after_crash **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 5 min read · 0 upvotes · 0 comments ## Summary The PostgreSQL parameter remove_temp_files_after_crash protects disk space by deleting orphaned temporary files after a backend crash, and should stay on in production. When one backend crashes, PostgreSQL kills every other backend with SIGQUIT, and quickdie() exits without running any cleanup, so every session's spill files and temp table storage become orphaned. Before PostgreSQL 14, these orphans stayed on disk until the next full postmaster start, and repeated crashes could fill the disk. Turning the parameter off only delays cleanup to the next start, not removes it: an AWS report from pgsql-hackers in September 2021 described cases including one customer with a little over 2.2 million leftover files, where cleanup had delayed recovery, and the author's sandbox test found 300,000 empty leftover files cost the postmaster 2.6 seconds to clean up. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What does the PostgreSQL remove_temp_files_after_crash parameter do? It controls whether the postmaster deletes orphaned temporary files during reinitialization after a backend crash, defaulting to on. When a backend crashes, PostgreSQL sends SIGQUIT to every other backend, which exits via _exit(2) without running cleanup callbacks, orphaning every session's spill files and temp table storage. Turning the parameter off only delays deletion to the next full postmaster start, it doesn't prevent it. _Teams tuning Postgres crash behavior can track GUC deep dives like this one on daily.dev._ ### Why does turning off remove_temp_files_after_crash not actually save me from the cleanup stall? Because the startup path never consults this parameter and always deletes leftover temp files unconditionally when the postmaster starts. Disabling it only postpones the deletion to the next start rather than avoiding it. An AWS report from pgsql-hackers (September 2021) described a customer with about 2.2 million leftover files whose startup cleanup badly delayed recovery, prompting RDS to move pgsql_tmp aside before starting the server. _Developers debugging Postgres startup stalls can follow ops-focused GUC breakdowns like this on daily.dev._ ### Why do other sessions' temporary files get deleted when a different PostgreSQL backend crashes? Because PostgreSQL treats any single backend crash as a crash of the whole instance: the postmaster sends SIGQUIT to every other child process, whose quickdie() handler exits via _exit(2) without running any cleanup, since shared memory may be corrupt. This orphans every session's spill files and temp table storage, not just the crashed backend's, including shared filesets from parallel queries. _Operators diagnosing orphaned Postgres temp files after a crash can find deep technical breakdowns like this via daily.dev._ ## Similar posts on daily.dev - [All Your GUCs in a Row: restart\_after\_crash](https://daily.dev/posts/all-your-gucs-in-a-row-restart-after-crash-reaeya0as) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: recovery\_end\_command](https://daily.dev/posts/all-your-gucs-in-a-row-recovery-end-command-o6sq0mrzj) · Planet PostgreSQL · 0 upvotes · 0 comments - [The four horsemen behind thousands of Postgres outages](https://daily.dev/posts/the-four-horsemen-behind-thousands-of-postgres-outages-tu19ush18) · Hacker News · 2 upvotes · 1 comments --- Tags: [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/all-your-gucs-in-a-row-remove-temp-files-after-crash-v1rldwbpj) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"All Your GUCs in a Row: remove_temp_files_after_crash","url":"https://daily.dev/posts/all-your-gucs-in-a-row-remove-temp-files-after-crash-v1rldwbpj","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-remove-temp-files-after-crash-v1rldwbpj"},"datePublished":"2026-10-25T01:02:20.359Z","dateModified":"2026-10-25T01:02:54.646Z","description":"The PostgreSQL parameter remove_temp_files_after_crash protects disk space by deleting orphaned temporary files after a backend crash, and should stay on in...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/532cbdd31ce4ee8cdd9a1d4c240e1b43?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/532cbdd31ce4ee8cdd9a1d4c240e1b43?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/all-your-gucs-in-a-row-remove-temp-files-after-crash-v1rldwbpj","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"postgresql","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"All Your GUCs in a Row: remove_temp_files_after_crash"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-remove-temp-files-after-crash-v1rldwbpj#faq","mainEntity":[{"@type":"Question","name":"What does the PostgreSQL remove_temp_files_after_crash parameter do?","acceptedAnswer":{"@type":"Answer","text":"It controls whether the postmaster deletes orphaned temporary files during reinitialization after a backend crash, defaulting to on. When a backend crashes, PostgreSQL sends SIGQUIT to every other backend, which exits via _exit(2) without running cleanup callbacks, orphaning every session's spill files and temp table storage. Turning the parameter off only delays deletion to the next full postmaster start, it doesn't prevent it. Teams tuning Postgres crash behavior can track GUC deep dives like this one on daily.dev."}},{"@type":"Question","name":"Why does turning off remove_temp_files_after_crash not actually save me from the cleanup stall?","acceptedAnswer":{"@type":"Answer","text":"Because the startup path never consults this parameter and always deletes leftover temp files unconditionally when the postmaster starts. Disabling it only postpones the deletion to the next start rather than avoiding it. An AWS report from pgsql-hackers (September 2021) described a customer with about 2.2 million leftover files whose startup cleanup badly delayed recovery, prompting RDS to move pgsql_tmp aside before starting the server. Developers debugging Postgres startup stalls can follow ops-focused GUC breakdowns like this on daily.dev."}},{"@type":"Question","name":"Why do other sessions' temporary files get deleted when a different PostgreSQL backend crashes?","acceptedAnswer":{"@type":"Answer","text":"Because PostgreSQL treats any single backend crash as a crash of the whole instance: the postmaster sends SIGQUIT to every other child process, whose quickdie() handler exits via _exit(2) without running any cleanup, since shared memory may be corrupt. This orphans every session's spill files and temp table storage, not just the crashed backend's, including shared filesets from parallel queries. Operators diagnosing orphaned Postgres temp files after a crash can find deep technical breakdowns like this via daily.dev."}}]} ```