So, for our production use, we want to achieve $subj. The problem is
not new [1], as well as solutions to it[2]. So, what is the problem?
On one hand, we cannot resolve this issue with some primitive log
chunk truncation mechanism inside core (the way it is done in
greenplum db for example[3]), because this will result in invalid json
logged in postgresql log file. Also, we maybe don't want to truncate
HINT or DETAIL (which should not be long). We only want to truncate
the query or its parameters list in case of extended proto. So, any
patch like this is probably unacceptable.
On the other hand, it is also unclear how to truncate long lines
inside emit_log_hook. I came up with this [4] module. This approach is
bad, because we modify core-owned data, so we break other
emit_log_hook hooks, which is a show stopper for this extension use.
The one detail we also should address is debug_query_string. We have
no API currently to tell the kernel to log debug_query_string
partially. One can set ErrorData hide_stmt field to true; but this way
we erase query string from logs, instead of logging to more than $N
chars (or multibyte sequence) from it.
So, I want to hear suggestions from the community, which way to
achieve $subj. The approach I have in mind right now is setting
something like field_max_length inside emit_log_hook. Then, use this
new setting in core in the send_message_to_server_log function.
[1] https://www.postgresql.org/message-id/CAM-gcbQqriv%3Dnr%3DYFFmp5ytgW7HbiftLBANFB9C0GwHMGDC0LA%40mail.gmail.com
[2] https://stackoverflow.com/questions/45992209/how-to-truncate-log-statement-in-postgres-9-6
[3]
https://github.com/greenplum-db/gpdb-archive/blob/283eea57100c690cb05b672b14eef7d0382e4e16/src/backend/utils/error/elog.c#L3668-L3671
[4] https://github.com/pg-sharding/pg_log_trunc/blob/master/pg_log_trunc.c#L43
--
Best regards,
Kirill Reshke
