Getting the Most of out Application_Name

March 15, 2017

Application_name might be one of those Postgres settings that you have seen in various places but never understood its purpose. It is true that setting application_name doesn't change the behavior of Postgres (with one small exception), but it is very useful for monitoring. Its value appears in pg_stat_activity and can be prepended to every log line with log_line_prefix.

Applications can set application_name when they connect as part of the connection string. Psql, pg_dump, and other tools set application_name. (They actually set fallback_application_name so application_name can be overridden by users.)

A more interesting use of application_name is to change it while the application is running. pgAdmin updates the application_name when a user changes screens so administrators can know exactly what screen users are on. While you can't change application_name while a query is running, you can change it between queries, which allows you to monitor the progress of long-running batch jobs, e.g.:

SELECT application_name
FROM pg_stat_activity
WHERE pid = pg_backend_pid();
 application_name
------------------
 psql

SET application_name = 'demo';

SELECT application_name
FROM pg_stat_activity
WHERE pid = pg_backend_pid();
 application_name
------------------
 demo

Some people might complain about the overhead of a separate query to update application_name. There are two solutions. One solution is to send two queries in a single string, e.g. select application_name = 'demo2'; select 100. Some libraries like libpq support this, but psql sends these as two separate queries — you have to enable log_statement to see how queries are sent to the server.

Another approach is to bundle the setting of application_name inside the query:

SELECT 100 FROM set_config('application_name', 'demo3', false);

SELECT application_name
FROM pg_stat_activity
WHERE pid = pg_backend_pid();
 application_name
------------------
 demo3

Unfortunately, there is no way to guarantee that set_config() will be run first, e.g. in the first query, set_config() is run first, and in the second query, run second, and the optimizer is allowed to run from-clause expressions in any order:

SELECT 100 FROM set_config('application_name', 'demo4', false), pg_sleep(5);

SELECT 100 FROM pg_sleep(5), set_config('application_name', 'demo5', false);

As you can see, application_name gives you a way to monitor what Postgres is doing, not only at connection time but during the life of the connection.

Bruce Momjian is Senior Database Architect at EnterpriseDB. 

This post originally appeared on Bruce's personal blog

Share this

Relevant Blogs

pgAdmin User Management in Server Mode

pgAdmin can be deployed as a web application by configuring the app to run in server mode. One can check out server deployment on how to run pgAdmin in...
August 24, 2023

pgAdmin CI/CD

Almost exactly three years ago I wrote a blog on my personal page entitled Testing pgAdmin which went into great detail discussing how we test pgAdmin prior to releases. Back...
August 24, 2023

More Blogs

Highlights from the PostgreSQL 16 Beta Release

The PostgreSQL Global Development Group released PostgreSQL 16 Beta 1 on May 25, 2023. PostgreSQL 16 improves logical replication by enabling replication from standbys as well as the ability to...
June 02, 2023