<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/all-your-gucs-in-a-row-exit-on-error-mgewbgoja" -->

---
title: All Your GUCs in a Row: exit_on_error | daily.dev
description: PostgreSQL's `exit_on_error` GUC promotes every ERROR to a session-terminating event, effectively killing the backend connection on any routine failure. While...
canonical: https://daily.dev/posts/all-your-gucs-in-a-row-exit-on-error-mgewbgoja
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: All Your GUCs in a Row: exit_on_error | daily.dev
og:description: PostgreSQL's `exit_on_error` GUC promotes every ERROR to a session-terminating event, effectively killing the backend connection on any routine failure. While...
og:url: https://daily.dev/posts/all-your-gucs-in-a-row-exit-on-error-mgewbgoja
og:image: https://api.daily.dev/og/posts/MgewBgOJa.png
og:image:alt: All Your GUCs in a Row: exit_on_error
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: exit_on_error

**[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 3 min read · 4 upvotes · 0 comments

## Summary

PostgreSQL's `exit_on_error` GUC promotes every ERROR to a session-terminating event, effectively killing the backend connection on any routine failure. While it sounds like a useful fail-fast mechanism, it operates at the OS process level rather than the script or transaction level, making it more destructive than helpful. Client-side tools like psql's `\set ON_ERROR_STOP on` already handle stopping on errors without destroying the connection. In interactive sessions it causes frustrating disconnects; behind a connection pooler it turns ordinary errors into pool churn. The only defensible use case is a single-purpose automated connection where you want the orchestrator to notice any failure immediately. In virtually all other cases, `exit_on_error` should be left off.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://postgr.es/p/9pW>

## Questions this post answers

### What does PostgreSQL's exit_on_error setting actually do?

It promotes every ERROR-level failure to a session-terminating event, meaning any routine error—a typo, a constraint violation, a division by zero—kills the database backend and closes the connection instead of just rolling back the current transaction. It is a boolean, off by default, with context 'user', so any role can enable it for a session, role, or database.

_Anyone tuning PostgreSQL error behavior can dig deeper into GUC settings and trade-offs via daily.dev._

### Why is exit_on_error a bad idea when using a connection pooler?

Because an ERROR that should roll back cleanly instead destroys a pooled backend and forces a reconnect, turning ordinary application errors into churn on the connection pool. This makes exit_on_error strictly more destructive than client-side error handling, which halts work while keeping the connection intact.

_Teams running pooled Postgres connections can weigh configuration risks like this through daily.dev._

### What is the correct way to make a batch of SQL statements stop at the first error in psql?

Use psql's \set ON_ERROR_STOP on, which halts execution of a script at the first failing statement while keeping the session and connection intact. This client-side approach achieves the 'stop at first failure' behavior people usually want, without the destructive session-killing side effect of enabling the exit_on_error server setting.

_Developers scripting reliable Postgres workflows can find practical configuration guidance via daily.dev._

## Similar posts on daily.dev

- [All Your GUCs in a Row: event\_triggers](https://daily.dev/posts/all-your-gucs-in-a-row-event-triggers-2eqdc3xmw) · Planet PostgreSQL · 1 upvotes · 0 comments
- [All Your GUCs in a Row: data\_sync\_retry](https://daily.dev/posts/all-your-gucs-in-a-row-data-sync-retry-i7zey1kmj) · Planet PostgreSQL · 0 upvotes · 0 comments
- [Resolving PostgreSQL ERROR: canceling statement due to user request](https://daily.dev/posts/resolving-postgresql-error-canceling-statement-due-to-user-request-8tlzte2il) · Baeldung · 1 upvotes · 0 comments
- [All Your GUCs in a Row: idle\_session\_timeout](https://daily.dev/posts/all-your-gucs-in-a-row-idle-session-timeout-m83cxdjmg) · 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: [#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-exit-on-error-mgewbgoja)

```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: exit_on_error","url":"https://daily.dev/posts/all-your-gucs-in-a-row-exit-on-error-mgewbgoja","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-exit-on-error-mgewbgoja"},"datePublished":"2026-07-17T01:03:53.187Z","dateModified":"2026-09-14T07:50:33.759Z","description":"PostgreSQL's `exit_on_error` GUC promotes every ERROR to a session-terminating event, effectively killing the backend connection on any routine failure. While...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f70f1e7bfd721dd7c40c6e295d85ef48?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f70f1e7bfd721dd7c40c6e295d85ef48?_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-exit-on-error-mgewbgoja","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,postgresql","timeRequired":"PT3M"}
{"@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: exit_on_error"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-exit-on-error-mgewbgoja#faq","mainEntity":[{"@type":"Question","name":"What does PostgreSQL's exit_on_error setting actually do?","acceptedAnswer":{"@type":"Answer","text":"It promotes every ERROR-level failure to a session-terminating event, meaning any routine error—a typo, a constraint violation, a division by zero—kills the database backend and closes the connection instead of just rolling back the current transaction. It is a boolean, off by default, with context 'user', so any role can enable it for a session, role, or database. Anyone tuning PostgreSQL error behavior can dig deeper into GUC settings and trade-offs via daily.dev."}},{"@type":"Question","name":"Why is exit_on_error a bad idea when using a connection pooler?","acceptedAnswer":{"@type":"Answer","text":"Because an ERROR that should roll back cleanly instead destroys a pooled backend and forces a reconnect, turning ordinary application errors into churn on the connection pool. This makes exit_on_error strictly more destructive than client-side error handling, which halts work while keeping the connection intact. Teams running pooled Postgres connections can weigh configuration risks like this through daily.dev."}},{"@type":"Question","name":"What is the correct way to make a batch of SQL statements stop at the first error in psql?","acceptedAnswer":{"@type":"Answer","text":"Use psql's \\set ON_ERROR_STOP on, which halts execution of a script at the first failing statement while keeping the session and connection intact. This client-side approach achieves the 'stop at first failure' behavior people usually want, without the destructive session-killing side effect of enabling the exit_on_error server setting. Developers scripting reliable Postgres workflows can find practical configuration guidance via daily.dev."}}]}
```

