Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uBtrX-007ysS-73 for pgsql-admin@arkaria.postgresql.org; Mon, 05 May 2025 11:19:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uBtrW-002tYx-Ap for pgsql-admin@arkaria.postgresql.org; Mon, 05 May 2025 11:19:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uBtrV-002tYi-Pn for pgsql-admin@lists.postgresql.org; Mon, 05 May 2025 11:19:53 +0000 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uBtrT-000FVo-0q for pgsql-admin@lists.postgresql.org; Mon, 05 May 2025 11:19:52 +0000 Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-223fb0f619dso48907245ad.1 for ; Mon, 05 May 2025 04:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746443991; x=1747048791; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3DDTWzCJCHa70d/Ss4Ez7qcF+7/eXJ6nvjHn3fzwayc=; b=M873GUCdZ+V2vUDOLZt8qc5BF0eNhGp8ugUrpULdnimFMKgFfUHDeBkODif/K35Dza mWzCLC8VEWCNUTIdpVGT/cY+WV4R1RTO2Cb54vVTMls3PElc4xQgJ5w6PaBunJj917zT ZGw+eFVkNDtWuC6o8ZrKTkiCV0iBHL5y/yrQoOt9D6iuyvrkmhyCyKckKLcfYdsBOPKm 3FlyEHInkP0LfWpn0B0hPgduCz9qdAjqpJX2VOyVetp0VDfD3VtTBycDjHK4/rejwOHg e5YCLyl6dLHyFQ6TXcfTsi7uC8+VB4ROsxcRNfNYD1linn3HuhtZrosynNYyPSNBvUAv +sQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746443991; x=1747048791; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3DDTWzCJCHa70d/Ss4Ez7qcF+7/eXJ6nvjHn3fzwayc=; b=hYGi5AdaQAEC4obgkKwkX0ourEfLOWotk9AT3LTm3LK0jTgT+VAWad0JEtVqus4ApO VAsuIBLkjJROmHWaj0EQdX3qBDMVuD7ojd0LPWwe5N0iNQHcmEWJQ6L7C8DvcY4y/y7Z iMlFXLBdtIVEVVj+fIICAr+gpZw/E/etb3utC4Cg/GV1IzhzkqPe5SjJ3r4UpVkpcKub Rx44ifQcxmGvu5PcNplj+HOaFQajsEK3sn3JUuzvAb4PzTEgAsOeB9AduhfqKjC25ssm yPA3DgJQoh4GCpKYkSSNZmz1CsWaQe7xpOF7dJbqxe48S5zDLKn0/cx5CMhwadaJZsXZ zxog== X-Gm-Message-State: AOJu0YwMcGSIeaptRsabR32Xr9HssRcS0ajB44NLQ4+teFFZzWBtN2Kg O7udFw/WmLOEl/7j6NHeaZR1ESAxlvPbsrc26w/CJhhTBqC1KedduF+XXS9lxDsa48Tsc+UQl0V UddiAVHfgsl0Hv6w1LS8CWWUc2zA48UurYuI= X-Gm-Gg: ASbGncsBjtfoXc+Or5jKREjSk3Wno2JTrX+fvANBt8enHa/kRit9I19Cl20JXKC6UPl nC0V7o9HqRsNOyxFWHXsdWwOvqh3dy/OGM9Ow548SeCEdpH3H2J/xUKhtZgcGl6ZL78pIfk5PV7 Z4O3biuDjXOBnTcI98SPF7TQ== X-Google-Smtp-Source: AGHT+IGUih3W8ZMzc+3e9pIOXoEz+BRDyrSC0jlyyMGO/PutFOs9YR4iUA9aqNBk/LVieeVdU7qbsmtBiAcXyND1gWI= X-Received: by 2002:a17:90b:548d:b0:305:2d27:7ba5 with SMTP id 98e67ed59e1d1-30a4e568050mr17239910a91.6.1746443990745; Mon, 05 May 2025 04:19:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pratik Pandit Date: Mon, 5 May 2025 16:49:39 +0530 X-Gm-Features: ATxdqUEzVtvCir37BocNQ26X5cwEhM1WMzVSOFyoib4bPLHkvn_FJoApvvJp4zI Message-ID: Subject: Re: Does PostgreSQL listen_addresses='*' Dynamically Detect New Interfaces To: Stelios Malathouras Cc: "pgsql-admin@lists.postgresql.org" Content-Type: multipart/alternative; boundary="000000000000b049ff063461adb6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000b049ff063461adb6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =3D '*'), 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 =E2=80=94 no corruption or instabilit= y 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=E2=80=AFPM 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 =3D '*', 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 the= m > without needing a service reload or restart? > > Thanks, > > *Stelios* > > > --000000000000b049ff063461adb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Stelios,

Yes, this behavior is typical for PostgreSQL when listen_addresses is set to '*'. When PostgreSQ= L is configured to listen on all available network interfaces (via li= sten_addresses =3D '*'), it dynamically detects new interfac= es and IP addresses without requiring a restart or service reload. So, as l= ong as listen_addresses is '*' and the ne= cessary network interfaces are configured correctly in the OS, PostgreSQL s= hould 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 bou= nd to '*' can accept connections immediately =E2=80=94= 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 o= n 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 failov= er


Thanks,
Pratik Pandit

On Mon, May 5, 2025 at 2:26=E2=80=AFPM Stelios Mala= thouras <s.malat= houras@deltasoftsolutions.net> wrote:
Hi,

We've scheduled for an IP change for one of our dedicated PostgreSQL se= rvers, running on version 13.8.
Our local tests, with listen_addresses =3D '*',=C2=A0=C2=A0show tha= t the postgres listener accepts connections immediately to the new IP.
The same behavior is observed=C2=A0when adding a new network interface.=C2= =A0 Postgres accepts connections to the new network interface (and IP) imme= diately without requiring a restart.

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

Thanks,

Stelios

=C2=A0

--000000000000b049ff063461adb6--