On 4/20/24 07:02, Lok P wrote:
> 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.
Have you tried?:
https://www.postgresql.org/docs/current/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHAT
"
log_statement (enum)
<...>
The default is none. Only superusers and users with the appropriate SET
privilege can change this setting.
"
Or
https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-SET
set_config ( setting_name text, new_value text, is_local boolean ) → text
>
> Now when we reach out to the infrastructure team , they are saying these
> variables(pg_cluster_log_statement,pg_instance_log_statement) were
Where are those variables coming from? I can not find them in RDS or
Terraform docs.
> 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
--
Adrian Klaver
adrian.klaver@aklaver.com