Log all postgres statements

[jancervenka]

Add log_statement = all to postgres.conf to log all statements
executed by postgres (DDL, DML, DQL).

Add log_lock_waits = on to log when a session is blocked waiting
for a lock longer than deadlock_timeout (1s default). This can
show suspicious behavior like someone holding locks to cause a
denial of service.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jancervenka
Once this PR has been reviewed and has the lgtm label, please assign lpiwowar for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jancervenka]

log_statement allows the following values

• none
• ddl: logs DDLs such as CREATE, DROP
• mod: logs DDLs and DMLs (INSERT, DELETE, etc.)
• all: logs everything (what is used in this PR)

Statement log example

2026-07-31 11:42:22.671 UTC [2963] LOG:  statement: CREATE TABLE test (x int);
2026-07-31 11:42:48.039 UTC [2975] LOG:  statement: INSERT INTO test VALUES (1)
2026-07-31 11:42:59.796 UTC [2979] LOG:  statement: SELECT * FROM test

Claude also recommends to add log_lock_waits = on to log when a session is blocked waiting for a lock longer than deadlock_timeout (1s default). This can show suspicious behavior like someone holding locks to cause a denial of service.

Log example

2026-07-31 12:07:34.180 UTC [3500] LOG:  process 3500 still waiting for AccessShareLock on relation 16603 of database 16385 after 1000.212 ms at character 15
2026-07-31 12:07:34.180 UTC [3500] DETAIL:  Process holding the lock: 3495. Wait queue: 3500.

I tested the change and it works but I found out that if you have an existing Lightspeed postgres pod and want to make changes to the postgres config, you need to delete the pod's PVC for the changes to take effect. Is that okay?

[umago]

I was reading about the log_statement = all and I'm not sure if it's a good idea to keep it always enabled, specially in production. See 0 or 1.

Setting log_statement = all in production is rarely worth it. It produces enormous volumes of logs and can measurably slow the server down, so most teams leave it off and reach for slow-query logging instead.

and

Warning: This setting can generate very large log files, especially in read-heavy workloads. Use with caution in production environments.

I wonder if we could add "postgres" to be part of the logging section and when it's set to debug we then inject this configuration: https://github.com/openstack-k8s-operators/lightspeed-operator/blob/main/api/v1beta1/openstacklightspeed_types.go#L116-L137

[jancervenka]

Thank you @umago that is a good point! I am looking into it and it is possible. One issue is that right now changing postgresLoglevel for example from INFO to DEBUG and running oc apply -f cr.yaml will not automatically reflect the change in the postgres pod. It requires deleting the postgres' PVC for the change to take effect. Is that okay?

If it is worth it to be able to apply changes without deleting the PVC, I will need to investigate a little bit more how to do it.