--- title: All Your GUCs in a Row: restart_after_crash | daily.dev description: The PostgreSQL parameter restart_after_crash controls whether the postmaster automatically restarts itself after a backend crash, and the author argues it... canonical: https://daily.dev/posts/all-your-gucs-in-a-row-restart-after-crash-reaeya0as twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: All Your GUCs in a Row: restart_after_crash | daily.dev og:description: The PostgreSQL parameter restart_after_crash controls whether the postmaster automatically restarts itself after a backend crash, and the author argues it... og:url: https://daily.dev/posts/all-your-gucs-in-a-row-restart-after-crash-reaeya0as og:image: https://api.daily.dev/og/posts/REaEyA0AS.png og:image:alt: All Your GUCs in a Row: restart_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: restart_after_crash **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 8 min read · 0 upvotes · 0 comments ## Summary The PostgreSQL parameter restart_after_crash controls whether the postmaster automatically restarts itself after a backend crash, and the author argues it should stay on. It's a boolean, default 'on', added in PostgreSQL 9.1, and changeable via reload since its context is sighup. With it on, a crash triggers full crash recovery automatically; on an idle test cluster this took about 120ms on both 18.6 and 19rc1, but 49 seconds after 7GB of WAL accumulated. With it off, the postmaster exits with status 1 and nothing restarts it, and PostgreSQL's own test suite sets it off. Clusterware like Patroni and pg_auto_failover leave it alone and watch the postmaster externally instead. On PostgreSQL 19rc1, a crash with one child that could not respond to SIGQUIT took 60 seconds to reach SIGKILL, against five seconds on 18.6, because of commit d1c01b79. ## 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 restart_after_crash parameter do? It controls whether the postmaster automatically restarts and runs crash recovery after a backend crash, or instead shuts down and exits with status 1, requiring external intervention. It is a boolean, default 'on', with context sighup, meaning a config reload applies the change without needing a full server restart. It was introduced in PostgreSQL 9.1. _daily.dev surfaces deep dives like this for engineers tuning PostgreSQL crash recovery and HA behavior._ ### Why do tools like Patroni not rely on PostgreSQL's restart_after_crash setting? Patroni, PAF, the Pacemaker pgsql agent, and pg_auto_failover all leave restart_after_crash alone and watch the postmaster from outside instead. Patroni's primary_start_timeout (default 300 seconds) sits on top of the postmaster's own restart behavior, controlling how long a crashed primary is allowed to recover in place before the clusterware triggers a failover. _Teams choosing a PostgreSQL HA strategy can track these clusterware tradeoffs on daily.dev._ ### Why did SIGKILL take 60 seconds instead of 5 seconds after a PostgreSQL crash on version 19 release candidate 1? A commit (d1c01b79) that added the automatic I/O worker pool reworked the postmaster's sleep calculation so the five-second grace period before SIGKILL is honored only during an immediate shutdown, not during a crash, pushing the wait up to a minute. On an idle 19rc1 cluster, a crash with one unresponsive child took 60 seconds to reach SIGKILL versus five seconds on 18.6. _Developers tracking PostgreSQL 19 regressions before upgrading can follow this kind of detail on daily.dev._ ## Similar posts on daily.dev - [All Your GUCs in a Row: remove\_temp\_files\_after\_crash](https://daily.dev/posts/all-your-gucs-in-a-row-remove-temp-files-after-crash-v1rldwbpj) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: recovery\_prefetch](https://daily.dev/posts/all-your-gucs-in-a-row-recovery-prefetch-hsgpjp4ga) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: hot\_standby](https://daily.dev/posts/all-your-gucs-in-a-row-hot-standby-wgsmgbrpp) · Planet PostgreSQL · 0 upvotes · 0 comments - [PostgreSQL Recovery Internals](https://daily.dev/posts/postgresql-recovery-internals-fyfrz2lny) · CYBERTEC PostgreSQL · 3 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/all-your-gucs-in-a-row-restart-after-crash-reaeya0as) ```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: restart_after_crash","url":"https://daily.dev/posts/all-your-gucs-in-a-row-restart-after-crash-reaeya0as","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-restart-after-crash-reaeya0as"},"datePublished":"2026-10-27T12:01:21.350Z","dateModified":"2026-10-27T12:01:51.728Z","description":"The PostgreSQL parameter restart_after_crash controls whether the postmaster automatically restarts itself after a backend crash, and the author argues it...","image":"https://media.daily.dev/image/upload/s--OHB84bZF--/f_auto/v1722860399/public/Placeholder%2010","thumbnailUrl":"https://media.daily.dev/image/upload/s--OHB84bZF--/f_auto/v1722860399/public/Placeholder%2010","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-restart-after-crash-reaeya0as","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,postgresql","timeRequired":"PT8M"} {"@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: restart_after_crash"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-restart-after-crash-reaeya0as#faq","mainEntity":[{"@type":"Question","name":"What does the PostgreSQL restart_after_crash parameter do?","acceptedAnswer":{"@type":"Answer","text":"It controls whether the postmaster automatically restarts and runs crash recovery after a backend crash, or instead shuts down and exits with status 1, requiring external intervention. It is a boolean, default 'on', with context sighup, meaning a config reload applies the change without needing a full server restart. It was introduced in PostgreSQL 9.1. daily.dev surfaces deep dives like this for engineers tuning PostgreSQL crash recovery and HA behavior."}},{"@type":"Question","name":"Why do tools like Patroni not rely on PostgreSQL's restart_after_crash setting?","acceptedAnswer":{"@type":"Answer","text":"Patroni, PAF, the Pacemaker pgsql agent, and pg_auto_failover all leave restart_after_crash alone and watch the postmaster from outside instead. Patroni's primary_start_timeout (default 300 seconds) sits on top of the postmaster's own restart behavior, controlling how long a crashed primary is allowed to recover in place before the clusterware triggers a failover. Teams choosing a PostgreSQL HA strategy can track these clusterware tradeoffs on daily.dev."}},{"@type":"Question","name":"Why did SIGKILL take 60 seconds instead of 5 seconds after a PostgreSQL crash on version 19 release candidate 1?","acceptedAnswer":{"@type":"Answer","text":"A commit (d1c01b79) that added the automatic I/O worker pool reworked the postmaster's sleep calculation so the five-second grace period before SIGKILL is honored only during an immediate shutdown, not during a crash, pushing the wait up to a minute. On an idle 19rc1 cluster, a crash with one unresponsive child took 60 seconds to reach SIGKILL versus five seconds on 18.6. Developers tracking PostgreSQL 19 regressions before upgrading can follow this kind of detail on daily.dev."}}]} ```