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 1uwk51-006rsX-UY for pgsql-admin@arkaria.postgresql.org; Thu, 11 Sep 2025 16:23:27 +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 1uwk4z-008zEN-Va for pgsql-admin@arkaria.postgresql.org; Thu, 11 Sep 2025 16:23:26 +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 1uwk3S-008u87-JW for pgsql-admin@lists.postgresql.org; Thu, 11 Sep 2025 16:21:51 +0000 Received: from mail-oo1-xc2b.google.com ([2607:f8b0:4864:20::c2b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uwk3R-001sAJ-14 for pgsql-admin@postgresql.org; Thu, 11 Sep 2025 16:21:50 +0000 Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-61ff7638f4eso351932eaf.2 for ; Thu, 11 Sep 2025 09:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757607708; x=1758212508; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=9CCsqjTOB+Lr7ilfx7WZD4IouMfugxtmtoAab4U3f84=; b=hw7bcm2O7Ey2d7wfPWOzoFuNv1ZrK4on9+vZtmBtQ0D5XDUY707hCtBy963ta6YRWJ 5c7Hsp53t/2hpXZbGxB22PUsmnME95nBVeBnj6cga3mxVHQImK2rFyPnq7ZTnPOaeh/R sdhb1kEmwVx1zI90wEDzKXwtm0T8dXpA966z5h45PjfWImpiTuGcB24I5ne1wzeRiMJ3 ybCnsOURpn3qpH0fjLooFp375OLVb3R5rW4lQx92DAgASAflrxyC8u2BiCadFP8b4Cqq ighjJcXJvHsjRWgE19vMMjSgSDm+BUJssj9flx6R0nBeV0uKvm1BAGPUVETi5yb125kT 1eKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757607708; x=1758212508; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9CCsqjTOB+Lr7ilfx7WZD4IouMfugxtmtoAab4U3f84=; b=spHqdbKaNtpdBTvxbXjk5uQE/H2RpTdghV4aXpH25eDcv+F0hPjQavVbtu2cLacxe0 396vvrGnzwQJFsSIe0j4dCJAeEfgUATlCwpVFG9hXOBbeurpbOcL+f+N2z4iXyEDackw aO2B954HgRCpuEBTdRtlnQjBRORLvbkVJ08xOuW4XrmCIu4TzhnHrhMlTJ/l0wIGD6ys 0V0eyOZgbXd54B79CyntGQGHw6QIC/ip0XZNlw76A35FqqwrUm+ZovgpSFtFIeBk9Qtt 2wBuFqUwlbigc9nV8P177Dw2nzycG4xtJThjw/J86AaE9qdr+E26SLxUwi0BA/Eyg0es JhtQ== X-Gm-Message-State: AOJu0YzzM1g7mRpjcExPwZ6IEfx0B6S6MlerxjQ/984H2umD5lHzlNqK +DwyOuhynd+hdfkctDQp4YS+RHudC7OztCYdgL2atWwr7ATuf1dKHfKtfIc8KwUGohhi1ssw2MF MCjiimJ53R/zTlao9BC/kjIECe7QCuUGW+OOu X-Gm-Gg: ASbGncv9M+tjV6fS9L9rYwMLNFtg7JSFgf4e40htwyAmJIOmypuYed4NOXs0+h3utiw oMjBNhHEJbSji+IAqm1PYTrUMpBPWEYJEFsVpq8V/1M0XbS6DI6CF0aavZ4hlZLJdSKPjvSFsFK S1WIgdCtYfzm/nhs5C6F+Cf+9xiN974B0vi0X1+NFwydzMprJPGu3rz6tgYImwVl5bCIMC+8alm TPENou6 X-Google-Smtp-Source: AGHT+IHYTcaNyayBUp7w9xNVFBhwYW4nlnZ2Jfqj20FhxBYkqxFNgKv42DbNZnTNGA94tPLB6n9Fn4UGn+L4B2r5h0s= X-Received: by 2002:a05:6870:1b19:b0:30b:7d90:1061 with SMTP id 586e51a60fabf-322627466e4mr10834640fac.4.1757607708442; Thu, 11 Sep 2025 09:21:48 -0700 (PDT) MIME-Version: 1.0 From: Ron Johnson Date: Thu, 11 Sep 2025 12:21:35 -0400 X-Gm-Features: Ac12FXzFGbTReHd1jELQM258qPGoVsi8fdVyDZ3UJKyzKraNRpgk2T_AJdHbc84 Message-ID: Subject: Allow connections by IP address? To: pgsql-admin Content-Type: multipart/alternative; boundary="0000000000001dc5df063e88efc8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001dc5df063e88efc8 Content-Type: text/plain; charset="UTF-8" PG 17.latest My server has two IP addresses: 10.1.2.3.4 10.1.2.3.5 (a VIP) Some connections should only come in through the VIP, while others (like replication) must come in through .4 and others (f.e. administrators, can come in from .4 or .5). Is there any way to restrict that? I don't see anything in https://www.postgresql.org/docs/17/auth-pg-hba-conf.html but may be overlooking something. (Why don't we use a connection pooler? The 3rd party application has only been validated against direct connections to PG. Bugs in PgPool caused problems in prod.) -- Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --0000000000001dc5df063e88efc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
PG 17.latest

My server has t= wo IP addresses:
10.1.2.3.4
10.1.2.3.5 (a VIP)

Some connections should only come in through the VIP, whil= e others (like replication) must come in through .4 and others (f.e. admini= strators, can come in from .4 or .5).

Is there any= way to restrict that?=C2=A0 I don't see anything in=C2=A0https://www.postgre= sql.org/docs/17/auth-pg-hba-conf.html but may be overlooking something.=

(Why don't we use a connection pooler?=C2=A0 = The 3rd party application has only been validated against direct=C2=A0conne= ctions to PG. Bugs in PgPool caused problems in=C2=A0prod.)

<= /div>--
Death to <Redacted>, and butter sauce.
Don't boil me, I= 9;m still alive.
<Redacted> lobster!
--0000000000001dc5df063e88efc8--