Re: Truncate logs by max_log_size

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Kirill Gavrilov <diphantxm(at)gmail(dot)com>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Euler Taveira <euler(at)eulerto(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Truncate logs by max_log_size
Date: 2026-04-09 18:11:38
Message-ID: CAHGQGwEc5Dn5KFU04sDp0Kyai2Te5yTuni3QW7pc2a3=343tJQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 9, 2026 at 5:52 AM Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> wrote:
> Moved tests to:
> src/test/modules/test_misc/t/012_log_statement_max_length.pl

Thanks for updating the patch! It looks good to me except the
following comments.

+$node->append_conf('postgresql.conf', "log_statement = 'all'\n");

This doesn't seem necessary, since $node->init already sets
log_statement = 'all'.

+$node->append_conf('postgresql.conf', "log_statement_max_length = 20\n");
+$node->reload();
+my $log_offset = -s $node->logfile;
+$node->psql('postgres', "SELECT '123456789ABCDEF'");

Would it be simpler (and cheaper) to use SET instead of reloading the
config? For example:

---------------------------
my $log_offset = -s $node->logfile;
$node->psql(
'postgres', "
SET log_statement_max_length TO 20;
SELECT '123456789ABCDEF';
");
---------------------------

+char *
+truncate_query_log(const char *query)

In elog.c, truncate_query_log() is currently placed between write_stderr() and
vwrite_stderr(). Since those two functions are related, it might be better to
move truncate_query_log() to a more appropriate location. Thoughts?

I see the patch has been moved to CommitFest PG20-1. Once development for v20
starts, I'd like to commit it.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-04-09 18:18:45 Re: test_autovacuum/001_parallel_autovacuum is broken
Previous Message Nathan Bossart 2026-04-09 18:10:29 Re: Add pg_stat_autovacuum_priority