unix_socket_directory

Definition PG 9.2 manual

Specifies the directory of the Unix-domain socket on which the server is to listen for connections from client applications. The default is normally /tmp, but can be changed at build time. This parameter can only be set at server start.

In addition to the socket file itself, which is named .s.PGSQL.nnnn where nnnn is the server's port number, an ordinary file named .s.PGSQL.nnnn.lock will be created in the unix_socket_directory directory. Neither file should ever be removed manually.

This parameter is irrelevant on Windows, which does not have Unix-domain sockets.

How it works

PostgreSQL describes unix_socket_directory as follows: “Sets the directory where the Unix-domain socket will be created.” The value is fixed when the server starts, so changing it requires a controlled restart. The atlas measures it in PG9.0–9.2; boot_val is the compiled or initialized baseline, not proof of a running cluster's effective setting.

This singular path setting selected the server's Unix-domain socket directory. PostgreSQL 9.3 replaced it with unix_socket_directories, a comma-separated list that can create sockets in multiple locations; group and permission controls remain separate.

Read it together with unix_socket_directories, unix_socket_group, unix_socket_permissions, listen_addresses. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Operational considerations

Treating the measured boot_val for unix_socket_directory as proof of the effective value on an initialized or managed cluster.

Applying a change as though it were immediate while pg_settings reports postmaster context.

Changing this setting in isolation without checking the linked limits, observability, and rollback path.

Copying the removed name into a modern postgresql.conf instead of migrating to its documented successor.

Workload guidance

OLAP: For an upgrade or analytical estate, inventory every generated configuration before cutover. Map the old control to its successor and compare plans, throughput, WAL, or logging behavior rather than assuming the old numeric value is portable.

OLTP: Do not add this retired name to a current OLTP configuration. Translate its intent to the documented successor, test the migration under connection and write concurrency, and remove stale automation that still emits it.

SMALL: Delete the obsolete override after recording why it existed. On a small node, prefer the successor's default until measurements justify a new value; an unknown startup parameter can otherwise stop the server.