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
