Thread: Does PostgreSQL listen_addresses='*' Dynamically Detect New Interfaces

Does PostgreSQL listen_addresses='*' Dynamically Detect New Interfaces

From
Stelios Malathouras
Date:
Hi,

We've scheduled for an IP change for one of our dedicated PostgreSQL servers, running on version 13.8.
Our local tests, with listen_addresses = '*',  show that the postgres listener accepts connections immediately to the new IP.
The same behavior is observed when adding a new network interface.  Postgres accepts connections to the new network interface (and IP) immediately without requiring a restart.

Is it safe to assume this is the default behaviour ? How does the instance detect new interfaces and their IP(s) and begin listening on them without needing a service reload or restart?  

Thanks,

Stelios

 

Hi Stelios,

Yes, this behavior is typical for PostgreSQL when listen_addresses is set to '*'. When PostgreSQL is configured to listen on all available network interfaces (via listen_addresses = '*'), it dynamically detects new interfaces and IP addresses without requiring a restart or service reload. So, as long as listen_addresses is '*' and the necessary network interfaces are configured correctly in the OS, PostgreSQL should continue functioning as expected without requiring a restart.

Why it is safe (under normal conditions) : -

  1. OS handles the interfaces: PostgreSQL trusts the OS to expose valid network interfaces. If the OS assigns a new IP, PostgreSQL bound to '*' can accept connections immediately — no corruption or instability risks.

  2. No restart required: As you observed, PostgreSQL doesn't need to rebind or restart because it's already listening on the wildcard interface (0.0.0.0 or :: for IPv6).

  3. Used in production setups: Many production systems with HA setups (e.g., floating IPs or VIPs) rely on this behavior during failover


Thanks,
Pratik Pandit

On Mon, May 5, 2025 at 2:26 PM Stelios Malathouras <s.malathouras@deltasoftsolutions.net> wrote:
Hi,

We've scheduled for an IP change for one of our dedicated PostgreSQL servers, running on version 13.8.
Our local tests, with listen_addresses = '*',  show that the postgres listener accepts connections immediately to the new IP.
The same behavior is observed when adding a new network interface.  Postgres accepts connections to the new network interface (and IP) immediately without requiring a restart.

Is it safe to assume this is the default behaviour ? How does the instance detect new interfaces and their IP(s) and begin listening on them without needing a service reload or restart?  

Thanks,

Stelios

 

Stelios Malathouras <s.malathouras@deltasoftsolutions.net> writes:
> Our local tests, with listen_addresses = '*',  show that the postgres listener accepts connections immediately to the
newIP. 
> The same behavior is observed when adding a new network interface.  Postgres accepts connections to the new network
interface(and IP) immediately without requiring a restart. 

It might be platform-dependent.  We call getaddrinfo(3) only once at
postmaster start, passing node = NULL if you said "*", and then
bind(2) to each resulting address.  The Linux manpage for getaddrinfo
quoth

       If  the  AI_PASSIVE  flag  is  specified in hints.ai_flags, and node is
       NULL,  then  the  returned  socket  addresses  will  be  suitable   for
       bind(2)ing  a  socket  that  will  accept(2) connections.  The returned
       socket address will contain the "wildcard address" (INADDR_ANY for IPv4
       addresses, IN6ADDR_ANY_INIT for IPv6 address).  The wildcard address is
       used by applications (typically servers) that intend to accept  connec‐
       tions  on  any  of  the host's network addresses.

The POSIX standard for getaddrinfo also says that these parameters
yield a wildcard address, but it doesn't say in so many words that
that results in accepting connections on any of the machine's
interfaces.  Maybe it says that elsewhere, though; I didn't go
digging.  In any case, you're probably fine on any Linux box,
but if you want to rely on this behavior on some other platform
I'd advise testing first.

            regards, tom lane



Re: Does PostgreSQL listen_addresses='*' Dynamically Detect New Interfaces

From
Stelios Malathouras
Date:

Thanks for explaining the internal mechanism, Tom.  Much appreciated.


Stelios Malathouras


 



From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Monday, May 5, 2025 5:31 PM
To: Stelios Malathouras <s.malathouras@deltasoftsolutions.net>
Cc: pgsql-admin@lists.postgresql.org <pgsql-admin@lists.postgresql.org>
Subject: Re: Does PostgreSQL listen_addresses='*' Dynamically Detect New Interfaces
 
Stelios Malathouras <s.malathouras@deltasoftsolutions.net> writes:
> Our local tests, with listen_addresses = '*',  show that the postgres listener accepts connections immediately to the new IP.
> The same behavior is observed when adding a new network interface.  Postgres accepts connections to the new network interface (and IP) immediately without requiring a restart.

It might be platform-dependent.  We call getaddrinfo(3) only once at
postmaster start, passing node = NULL if you said "*", and then
bind(2) to each resulting address.  The Linux manpage for getaddrinfo
quoth

       If  the  AI_PASSIVE  flag  is  specified in hints.ai_flags, and node is
       NULL,  then  the  returned  socket  addresses  will  be  suitable   for
       bind(2)ing  a  socket  that  will  accept(2) connections.  The returned
       socket address will contain the "wildcard address" (INADDR_ANY for IPv4
       addresses, IN6ADDR_ANY_INIT for IPv6 address).  The wildcard address is
       used by applications (typically servers) that intend to accept  connec‐
       tions  on  any  of  the host's network addresses.

The POSIX standard for getaddrinfo also says that these parameters
yield a wildcard address, but it doesn't say in so many words that
that results in accepting connections on any of the machine's
interfaces.  Maybe it says that elsewhere, though; I didn't go
digging.  In any case, you're probably fine on any Linux box,
but if you want to rely on this behavior on some other platform
I'd advise testing first.

                        regards, tom lane