Skip to Content

How to Kill a PostgreSQL Session: A Complete Guide for Database Administrators

In PostgreSQL, managing sessions is crucial for ensuring smooth database performance.

Whether a query is running too long, a session is blocking other processes, or you need to clean up idle connections, knowing how to kill a PostgreSQL session can help you resolve these issues.

In this guide, we’ll walk you through the steps to identify, cancel, and forcefully terminate problematic sessions in PostgreSQL, helping you maintain optimal database performance.

Why You Might Need to Kill a PostgreSQL Session

There are various reasons why you may need to terminate a PostgreSQL session:

Get Your Free Linux training!

Join our free Linux training and discover the power of open-source technology. Enhance your skills and boost your career! Learn Linux for Free!
  • Long-running queries that affect system performance
  • Session blocking other processes, preventing essential queries from running
  • Idle sessions that unnecessarily consume resources
  • Unresponsive sessions that could be stuck or waiting indefinitely

Understanding when and how to intervene in PostgreSQL sessions will help you troubleshoot and maintain a healthy database environment.

Step 1: Identify the PostgreSQL Session Using the PID

Before terminating a session, you need to identify its Process ID (PID). You can easily retrieve this information by querying the pg_stat_activity system view, which shows all active sessions in your PostgreSQL database.

SQL Query to Identify Active Sessions

SELECT datname, usename, pid, query
FROM pg_stat_activity
WHERE state = 'active'
  AND backend_type = 'client backend';

This query will return the following details for each active session:

  • datname: The name of the database the session is connected to
  • usename: The username of the session owner
  • pid: The backend process ID, which is required to cancel or terminate the session
  • query: The query currently being executed by the session

Once you have the pid, you can proceed with canceling or terminating the session.

Step 2: Gracefully Cancel the Running Query

The first approach to terminating a session is to cancel the query that is currently running. PostgreSQL provides the pg_cancel_backend() function to interrupt a query gracefully. This approach should be your first choice as it is less disruptive than forcefully terminating the session.

SQL Query to Cancel a Query

SELECT pg_cancel_backend(12345);

Replace 12345 with the actual pid of the backend process you want to cancel.

Key Points to Remember:

  • This method only works if the session is actively running a query.
  • It can be executed by the user who owns the backend session or by a superuser.
  • The query will be interrupted, but the session itself remains active. This gives the session the chance to continue working if needed.

Step 3: Forcefully Terminate the Session (Last Resort)

If the session is idle or the query cancellation didn’t work, you may need to forcefully terminate the backend session. This can be done using the pg_terminate_backend() function.

SQL Query to Terminate a Session

SELECT pg_terminate_backend(12345);

Once again, replace 12345 with the target pid. This function will:

  • Terminate the backend process, even if it is idle or stuck within a transaction.
  • Disconnect the client: The client application will lose its connection to the database, which may require the client to reconnect or display an error.

Important Considerations When Forcefully Terminating a Session

  • Permissions: Only superusers can terminate sessions owned by other superusers. Regular users can only cancel or terminate their own sessions.
  • Impact: Forcefully terminating a session may cause transactions to roll back, so be sure to check the impact on application performance and user experience.

Step 4: Terminating PostgreSQL Sessions via Command Line (Advanced)

While PostgreSQL’s internal functions (pg_cancel_backend and pg_terminate_backend) are preferred, you may also use the command line to terminate a PostgreSQL session directly. This method bypasses PostgreSQL’s internal management and should only be used with caution.

Using ps and kill Commands

1. Find the Process ID (PID): Use the ps command to find PostgreSQL processes:

ps aux | grep postgres

2. Terminate the Process: Once you identify the correct PID, use the kill command to send a termination signal:

kill -9 <PID>

Warning: Terminating a session via the command line can have unintended consequences. Always try using PostgreSQL’s internal functions first to maintain the integrity of your database.

Best Practices for Managing PostgreSQL Sessions

1. Monitor Long-Running Queries

Regularly check for long-running queries using the pg_stat_activity view. Monitoring these queries helps you avoid performance bottlenecks before they become problematic.

2. Set statement_timeout for Automatic Query Cancellation

The statement_timeout configuration parameter can automatically cancel any query that exceeds a specified time limit, reducing the need for manual intervention.

3. Resolve Locking Issues

Lock contention can often lead to blocking sessions. Investigate the root causes of blocking and resolve them directly by addressing locking problems.

4. Avoid Forceful Termination Unless Necessary

Terminate sessions forcefully only as a last resort. Always try to cancel queries gracefully and address any underlying issues that cause long-running or blocked sessions.

Conclusion: Efficiently Manage PostgreSQL Sessions

Killing a PostgreSQL session can be an effective way to resolve issues like long-running queries, session blocks, or unresponsive backends. However, it’s crucial to use the appropriate method—whether that’s gracefully canceling a query or forcefully terminating a session—depending on the severity of the issue.

By following the steps outlined above, you’ll be able to manage and resolve problematic sessions with minimal disruption. Regular monitoring and using tools like statement_timeout can further help reduce the need for manual intervention, keeping your PostgreSQL environment running smoothly.