Re: Truncate logs by max_log_size

Kirill Gavrilov <diphantxm@gmail.com>

From: Kirill Gavrilov <diphantxm@gmail.com>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: Jim Jones <jim.jones@uni-muenster.de>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Euler Taveira <euler@eulerto.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-11-30T08:44:00Z
Lists: pgsql-hackers
>
>
> Hi
>
> > +for (my $attempts = 0; $attempts < $max_attempts; $attempts++)
> > +{
> > + eval {
> > + $current_logfiles = slurp_file($node->data_dir . '/current_logfiles');
> > + };
> > + last unless $@;
> > + usleep(100_000);
> > +}
>
>
> `usleep` in tap tests is usually a bad pattern. Do we have a chance to
> test this using `wait_for_log` or similar?
>

I'm not sure we can use `wait_for_log` because it checks for only one
logfile. But even if it's possible, I don't think it's a good idea to use
different checks in the same file or to change tests for another feature. I
used test case from above as an example for mine.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix log_statement_max_length test with verbose logs

  2. Add log_statement_max_length GUC to limit logged statement text

  3. Improve user control over truncation of logged bind-parameter values.