Skip Navigation
Show nav
Dev Center
  • Get Started
  • Documentation
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
    • .NET
  • Documentation
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Visit the Heroku Blog

    Find news and updates from Heroku in the blog.

    Visit Blog
  • Log inorSign up
Hide categories

Categories

  • Heroku Architecture
    • Compute (Dynos)
      • Dyno Management
      • Dyno Concepts
      • Dyno Behavior
      • Dyno Reference
      • Dyno Troubleshooting
    • Stacks (operating system images)
    • Networking & DNS
    • Platform Policies
    • Platform Principles
  • Developer Tools
    • Command Line
    • Heroku VS Code Extension
  • Deployment
    • Deploying with Git
    • Deploying with Docker
    • Deployment Integrations
  • Continuous Delivery & Integration (Heroku Flow)
    • Continuous Integration
  • Language Support
    • Node.js
      • Working with Node.js
      • Node.js Behavior in Heroku
      • Troubleshooting Node.js Apps
    • Ruby
      • Rails Support
      • Working with Bundler
      • Working with Ruby
      • Ruby Behavior in Heroku
      • Troubleshooting Ruby Apps
    • Python
      • Working with Python
      • Background Jobs in Python
      • Python Behavior in Heroku
      • Working with Django
    • Java
      • Java Behavior in Heroku
      • Working with Java
      • Working with Maven
      • Working with Spring Boot
      • Troubleshooting Java Apps
    • PHP
      • PHP Behavior in Heroku
      • Working with PHP
    • Go
      • Go Dependency Management
    • Scala
    • Clojure
    • .NET
      • Working with .NET
  • Databases & Data Management
    • Heroku Postgres
      • Postgres Basics
      • Postgres Getting Started
      • Postgres Performance
      • Postgres Data Transfer & Preservation
      • Postgres Availability
      • Postgres Special Topics
      • Migrating to Heroku Postgres
    • Heroku Key-Value Store
    • Apache Kafka on Heroku
    • Other Data Stores
  • AI
    • Model Context Protocol
    • Vector Database
    • Heroku Inference
      • Inference Essentials
      • AI Models
      • Inference API
      • Quick Start Guides
    • Working with AI
  • Monitoring & Metrics
    • Logging
  • App Performance
  • Add-ons
    • All Add-ons
  • Collaboration
  • Security
    • App Security
    • Identities & Authentication
      • Single Sign-on (SSO)
    • Private Spaces
      • Infrastructure Networking
    • Compliance
  • Heroku Enterprise
    • Enterprise Accounts
    • Enterprise Teams
    • Heroku Connect (Salesforce sync)
      • Heroku Connect Administration
      • Heroku Connect Reference
      • Heroku Connect Troubleshooting
  • Patterns & Best Practices
  • Extending Heroku
    • Platform API
    • App Webhooks
    • Heroku Labs
    • Building Add-ons
      • Add-on Development Tasks
      • Add-on APIs
      • Add-on Guidelines & Requirements
    • Building CLI Plugins
    • Developing Buildpacks
    • Dev Center
  • Accounts & Billing
  • Troubleshooting & Support
  • Integrating with Salesforce
  • Databases & Data Management
  • Heroku Postgres
  • Postgres Performance
  • Correctly Establishing Postgres Connections in Forked Environments

Correctly Establishing Postgres Connections in Forked Environments

English — 日本語に切り替える

Last updated October 16, 2024

Table of Contents

  • Forked environments
  • Database connection pools
  • Ruby on Rails
  • Unicorn server
  • Resque Ruby queuing
  • Sidekiq
  • Disabling New Relic EXPLAIN

By design, connections to Postgres databases are persistent to reduce the performance impact of having to re-establish a connection for every invocation. While this increases the performance of your application it also requires properly establishing the connection, especially in forked environments.

Forked environments

If you’re using a framework or library that uses forked processes, connections to Postgres (and any other resources) should be established after the fork completes. This ensures that each forked process has its own connection and avoids several of the most common connection errors such as no connection to the server and SSL SYSCALL error: EOF detected and SSL error: decryption failed or bad record mac.

Connection instructions for several common frameworks and libraries are included here.

Database connection pools

When using a fork-based server of any kind, each fork receives its own database connection pool. For this reason, most applications using fork-based web servers receive the best performance when the application-level (for example, Rails, Sequel, or Django) connection pool isn’t used, or used with a pool size of one.

Overuse of database connections can result in lower overall performance, “out of memory” errors reported by the database server, and the database server’s refusal to accept connections from additional clients (connection limit reached).

Applications that are exempt from this advice tend to have been purposefully written to take advantage of or require multiple simultaneous transactions within the context of a single HTTP request.

Ruby on Rails

Important Postgres reconnection bugs have been fixed in ActiveRecord 3.2.9. Previous releases (3.1, 3.0, 2.x) haven’t received these enhancements. If you’re using ActiveRecord 3.2, upgrading to version 3.2.9 or later is recommended.

For previous versions, exiting the process when PGError is propagated from the application is recommended since Heroku will automatically restart crashed dynos.

Unicorn server

Unicorn is a Rack HTTP server that uses forked process to handle incoming requests. Specify the before and after fork behavior in the unicorn.conf configuration file.

In a Rails app or an app using ActiveRecord, add the following before_fork and after_fork blocks in unicorn.conf:

before_fork do |server, worker|

  Signal.trap 'TERM' do
    puts 'Unicorn master intercepting TERM and sending myself QUIT instead'
    Process.kill 'QUIT', Process.pid
  end

  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.connection.disconnect!
end

after_fork do |server, worker|

  Signal.trap 'TERM' do
    puts 'Unicorn worker intercepting TERM and doing nothing. Wait for master to sent QUIT'
  end

  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection(
      Rails.application.config.database_configuration[Rails.env]
    )

end

Resque Ruby queuing

Resque uses forking to create new worker processes. The main process connection should be disconnected before forking (to avoid consuming unnecessary resources) while worker connections should be established after the fork occurs.

You can specify this behavior by cleaning up and re-establishing connections in an initializer:

  Resque.before_fork do
    defined?(ActiveRecord::Base) and
      ActiveRecord::Base.connection.disconnect!
  end

  Resque.after_fork do
    defined?(ActiveRecord::Base) and
      ActiveRecord::Base.establish_connection
  end

Sidekiq

Sidekiq uses threads to handle many jobs at the same time in the same process. To prevent sharing of connections you must configure the Sidekiq server to correctly establish its own connection.

You can specify this behavior by cleaning up and re-establishing connections in a Sidekiq initializer:

See Concurrency and Database Connections for Background Workers

Disabling New Relic EXPLAIN

The current implementation of New Relic auto-EXPLAIN can cause one extra database connection to be used per fork. For high-volume applications that cannot tolerate the extra connection, it may be worthwhile to disable the automatic EXPLAIN feature of New Relic. For instructions about how to do this, see the New Relic documentation in Manually changing your configuration.

As an alternative, if you’re using Postgres 9.2 or later, consider using pg_stat_statements. Useful in its own right, it can also help mitigate some of the loss in visibility caused by disabling New Relic’s auto-EXPLAIN.

Keep reading

  • Postgres Performance

Feedback

Log in to submit feedback.

Understanding Heroku Postgres Data Caching Efficient Use of PostgreSQL Indexes

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure
  • .NET

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing
  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Github
  • LinkedIn
  • © 2025 Salesforce, Inc. All rights reserved. Various trademarks held by their respective owners. Salesforce Tower, 415 Mission Street, 3rd Floor, San Francisco, CA 94105, United States
  • heroku.com
  • Legal
  • Terms of Service
  • Privacy Information
  • Responsible Disclosure
  • Trust
  • Contact
  • Cookie Preferences
  • Your Privacy Choices