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 1tI9Nr-00CVPR-K0 for pgsql-admin@arkaria.postgresql.org; Mon, 02 Dec 2024 16:34:51 +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 1tI9Np-001Dj5-4O for pgsql-admin@arkaria.postgresql.org; Mon, 02 Dec 2024 16:34:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tI9No-001Dix-PE for pgsql-admin@lists.postgresql.org; Mon, 02 Dec 2024 16:34:49 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tI9Nn-000gL9-0w for pgsql-admin@lists.postgresql.org; Mon, 02 Dec 2024 16:34:49 +0000 Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-53dd8b7796dso4699673e87.1 for ; Mon, 02 Dec 2024 08:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733157285; x=1733762085; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Gin7vMzTG2MPTo6AkPabw3Yge5ZJNvH7/zb3zueV8Us=; b=FBw1SjwOq7pE7OidmEHV9TAu8+PbeKcWrdJSjGGSaChqVE8rkiSkeSR4orEsaPEMAN oA+ZtzpuXGTFZMI9C2O+AwHQ2+9BjjXphoY9LhpuWq0ep2xXXj4tn7MEMqGPO9NjTwDP qVcUXd1dSsoHY+EG5J0NlNWgA5JrHOv29FfH/vIjSc9R49ooTNSaBwNvnMk5EUP/VgFh gRUfgqYIZ3DtKmYxBiJ4906pmaxGPWkvTdhMCkZduKMgVsAtYU6a32H9eRMrd9amac1S oa1vgI1meobKe/7RJdr3YWDx5t57UJBxji7dSmINI+1Hq1zlDX/6i0AfHqiIzm5QQZxT ez/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733157285; x=1733762085; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Gin7vMzTG2MPTo6AkPabw3Yge5ZJNvH7/zb3zueV8Us=; b=kpssSFc8MCj6Z7PIT3Hu38LYfflFs0dfatPDia8S1QUFSsIjLJ7skDIShteTltHmzE MrD3UrjjkwyXTlS/7moHUrSsZcJ0/HozQqBLP/DCcZiugDiiWIAMw0ZTMO2OUghm4IZQ iX6xVIvaSa36Zz2BygqsB/cfeirR9GEk6z/2iOXHENdtb6YKr/1StgZ97+h97ZHWnxxG ncY+wKIXQSzmH/GnUHVmp3r+iaI5BX+0oRgffS6jdF9AO1FjZ8okr8VAMJpcoq2QMZel E2j1p0Hj5VM8nL3HnqQJw4duei6EiZDr9qfwCZ7U7q5eSkGWewjvu+RlImlNK/umgr9d +ovw== X-Gm-Message-State: AOJu0YxojBcE5VKP4VizTJjmR74/Zt/OImB9bWyvv4nynMjzsaMz39tg uePR05jk+abrtdQeGOhDBlrUp3wfc6Xt450pKnkkD6wIWdJ+NBS7dJuyI7znol+Mk8tw6t45Hba diXtWjPEsz6L9vcMuwUV9dM5qOdCKsOqQ X-Gm-Gg: ASbGncvp40pS++N6yZ/0uphT2eAYxKB+Bi6EFzXQK9NcBI1+ORgUU9CuX/XijgDmkkx LPxTZvkyqPPxZXYbkTgeM1G94ObtEXaHR X-Google-Smtp-Source: AGHT+IEa+KQ9toklFhvY8K29AAEDDFS4XU3nvzTyRG9VDz46cWfPiexSB6106/6atdp/mGt5ybqz3O0IrhaDCANhR24= X-Received: by 2002:a19:f51a:0:b0:53d:f983:a57 with SMTP id 2adb3069b0e04-53df9830acdmr8090017e87.3.1733157284538; Mon, 02 Dec 2024 08:34:44 -0800 (PST) MIME-Version: 1.0 From: Erik Serrano Date: Mon, 2 Dec 2024 13:34:33 -0300 Message-ID: Subject: Database disconnection due to timeout To: Pgsql-admin Content-Type: multipart/alternative; boundary="00000000000048f66c06284c20ae" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000048f66c06284c20ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi guys, nice to meet you .. I have to solve a user problem against the postgresql database that is located in the Azure cloud as (IaaS) that is happening to you the following: A user drops the connection from his console to the replica slave database due to timeout, it is possible that there is a parameter within the configuration file (postgresql.conf) connection (pg_hba.conf) or replica manager (repmgr.conf) that allows me to solve this problem. Background: - The database is in an Azure IaaS. - The database allows the connection, but the user drops due to timeout - I can connect to the same server and database with their credentials - Firewall allows the connection. - the configuration in pg_hba.conf owns the user - user connects through DBeaver - The database postgreSQL is version 15 - user is the owner of the database Any contribution is appreciated. Thank you very much for your contributions and help. Greetings *Erik R. Serrano Saavedra* *Ingeniero de Sistemas Inform=C3=A1ticos* --00000000000048f66c06284c20ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi guys, nice to meet you .. I have to solve a user p= roblem against the postgresql database that is located in the Azure cloud a= s (IaaS) that is happening to you the following:

A user drops the co= nnection from his console to the replica slave database due to timeout, it = is possible that there is a parameter within the configuration file (postgr= esql.conf) connection (pg_hba.conf) or replica manager (repmgr.conf) that a= llows me to solve this problem.


Background:
- The database is= in an Azure IaaS.
- The database allows the connection, but the user dr= ops due to timeout
- I can connect to the same server and database with = their credentials
- Firewall allows the connection.
- the configurati= on in pg_hba.conf owns the user
- user connects through DBeaver
- The= database postgreSQL is version 15
- user is the owner of the database

Any contribution is appreciated.

Thank you very much for your contributions and help.
Greetings


Erik R= . Serrano Saavedra
<= b>Ingeniero de Sistemas Inform=C3=A1ticos

=
--00000000000048f66c06284c20ae--