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 1ryBIw-00ExTn-2X for pgsql-general@arkaria.postgresql.org; Sat, 20 Apr 2024 14:02:58 +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 1ryBIs-00AAUB-Ur for pgsql-general@arkaria.postgresql.org; Sat, 20 Apr 2024 14:02: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 1ryBIs-00AAU3-IE for pgsql-general@lists.postgresql.org; Sat, 20 Apr 2024 14:02:54 +0000 Received: from mail-yw1-x1131.google.com ([2607:f8b0:4864:20::1131]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ryBIq-003mCC-45 for pgsql-general@lists.postgresql.org; Sat, 20 Apr 2024 14:02:53 +0000 Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-61adcdf6b9dso5489617b3.0 for ; Sat, 20 Apr 2024 07:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713621771; x=1714226571; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=/JiT/m8ljiRrkdSKCi4KsFeu2X1zL7NHVt3iD0LRAwU=; b=OheitryZ059kqtdc9f78TPhadTWJ20JblA0nfC035eyDwqdcXxVMOcCwPy4Rf++DHL /JGMnPNU1n7HAP3w9W7/Jt/U5H/9OCKc6+CMGMcJpLX6+dcoFKobEOUT9rqojA+GwRg4 14MnKXDqaxSmd74eQjCJkoJz2Z06MRJPJpFfSibtOVXRGraGLIVqeg60VVdeEWBidR/Q MuAO0SQVFFQY2tPQBaZ0NHTs+P6c7/dimaUuswDxRMGCF7DG1iO/rFWqNBFLzYuoz4iB D/zl+NQr+panWcdR/TJeXKIb0u5FJLmyRlz+cYeOKo0t7ITFmysZUI0HCvghL/rhtTyA +Wmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713621771; x=1714226571; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=/JiT/m8ljiRrkdSKCi4KsFeu2X1zL7NHVt3iD0LRAwU=; b=N5ul14pAlLre5gWkV3WXdRZCwqvXiyqPLizBPyXb3eg9nsfp8tvq/qZKueTVdj/4u9 tlkAlkl4RHdzXo1gHiuzbbjVUjv48ygvVCE23NR2XACQxgENIG1/lAoEtOGcvJvCWLWB vCA8WzU2a/GjujaxTwBjIiO1IJX+lRyahcCsSFjP+guC0D1NHYF5vRxxFrHdg8GfLeE/ NSm8NudRsHiOcJGy1HguZNk4lHEpW/zGHrl7lq1qFMrc/FitPOnLNkXvjuc+a/18kvIY GjU3Vc8hL0ttYSc8p9FvODjhNJSHfR91P6H90MKQfSuUJ4+KUS0DHumLtdGu3vSRQx/z lUfQ== X-Gm-Message-State: AOJu0Yztg+Rlt++hzCbDpG8yaVi9qBGyl28bSLGkcCMHiEsAGqdvSGh2 4rul9ic7+wfyuDhO9FyFsJpY3hu1gV4s09juSrLsOOMcbuccrRiSjdWtffxWLmme/nWBuhl0WU5 hrX5rvyAjBwFZFHXZzmC1D3hbc2PpBVgU X-Google-Smtp-Source: AGHT+IF9vv2j+xg33ErWN5ASBzlTHixa4Frf8YsisIX3/SzcmIbl1r7UmSePW29UxAGQ4b6tgLVoLbQsMnFnqyfIP+w= X-Received: by 2002:a25:abd2:0:b0:dcb:cdbd:6594 with SMTP id v76-20020a25abd2000000b00dcbcdbd6594mr3092648ybi.3.1713621771058; Sat, 20 Apr 2024 07:02:51 -0700 (PDT) MIME-Version: 1.0 From: Lok P Date: Sat, 20 Apr 2024 19:32:39 +0530 Message-ID: Subject: Logging statement having any threat? To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000f18b0f061687a808" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f18b0f061687a808 Content-Type: text/plain; charset="UTF-8" Hello All, Its postgres version 15.4 and its RDS, in which our dev team gets the infrastructure code from another third party team which provides us base infrastructure code to build a postgres database, in which we will be able to do change DB parameter values etc whatever is mentioned in the file with possible values. But surprisingly we don't see log_statement there. Below was our requirement, For debugging and evaluating performance we were having pg_stat_statements but it contains aggregated information about all the query execution. But in case just want to debug any point in time issues where the selected few queries were performing bad (may be because of plan change), we were planning to have the auto_explain extension added and set the log_min_duration to ~5 seconds, So that, all the queries going above that time period(5 seconds) will be logged and provide detailed information on the exact point of bottleneck. But we see the log_statement parameter has been removed from the base infrastructure script/terraform script given by the database team here, so that means we will get it as default which is "NONE", which means no statement(SELECT/DML/DDL etc) can be logged. Now when we reach out to the infrastructure team , they are saying these variables(pg_cluster_log_statement,pg_instance_log_statement) were removed due to potential security threat. So I want to understand from experts here , how this is really a security threat and if any option to get this logging enabled (which will help us debug performance issues) at same time addressing the threat too? Regards Lok --000000000000f18b0f061687a808 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All,
Its postgres version 15.4 and its RDS, in w= hich our dev team gets the infrastructure code from another third party tea= m which provides us base infrastructure code to build a postgres database, = in which we will be able to do change DB parameter values etc whatever is m= entioned in the file with possible values. But surprisingly we don't se= e log_statement there. Below was our requirement,

For debugging and = evaluating performance we were having pg_stat_statements but it contains ag= gregated information about all the query execution. But in case just want t= o debug any point in time issues where the selected few queries were perfor= ming bad (may be because of plan change), we were planning to have the auto= _explain extension added and set the log_min_duration to ~5 seconds, So tha= t, all the queries going above that time period(5 seconds) will be logged a= nd provide detailed information on the exact point of bottleneck. But we se= e the log_statement parameter has been removed from the base infrastructure= script/terraform script given by the database team here, so that means we = will get it as default which is "NONE", which means no statement(= SELECT/DML/DDL etc) can be logged.

Now when we reach out to the inf= rastructure team , they are saying these variables(pg_cluster_log_statement= ,pg_instance_log_statement) were removed due to potential security threat. = So I want to understand from experts here , how this is really a security t= hreat and if any option to get this logging enabled (which will help us deb= ug performance issues) at same time addressing the threat too?

=
Regards=C2=A0
Lok
--000000000000f18b0f061687a808--