Thread: Why does wait_for_log() return current file size

Hi,

In a test I'd like to use wait_for_log() to find a bunch of log messages
emitted in sequence. A reasonable looking pattern for that would be:

    $log_location = -s $node->logfile;

        $log_location = $node->wait_for_log(qr/first-message/, $log_location);
        $log_location = $node->wait_for_log(qr/second-message/, $log_location);

Except that that doesn't work, because what wait_for_log returns is:

        my $log =
          PostgreSQL::Test::Utils::slurp_file($self->logfile, $offset);

        return $offset + length($log) if ($log =~ m/$regexp/);

Which, afaict, boils down to the current end of the logfile.

Could we instead determine where in the string our regex matched, and return
   $offset + $that_magic_number

Assuming that could be made work, does anybody see a reason not to do that?

Greetings,

Andres Freund

Hi,

In a test I'd like to use wait_for_log() to find a bunch of log messages
emitted in sequence. A reasonable looking pattern for that would be:
	$log_location = -s $node->logfile;
        $log_location = $node->wait_for_log(qr/first-message/, $log_location);        $log_location = $node->wait_for_log(qr/second-message/, $log_location);

Except that that doesn't work, because what wait_for_log returns is:
		my $log =		  PostgreSQL::Test::Utils::slurp_file($self->logfile, $offset);
		return $offset + length($log) if ($log =~ m/$regexp/);

Which, afaict, boils down to the current end of the logfile.

Could we instead determine where in the string our regex matched, and return   $offset + $that_magic_number

Assuming that could be made work, does anybody see a reason not to do that?

In principle it seems quite reasonable, but I haven't looked at all the current uses to see if they will be upset.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Hi,

On 2025-03-29 12:09:58 -0400, Andrew Dunstan wrote:
> On 2025-03-29 Sa 11:15 AM, Andres Freund wrote:
> > Hi,
> >
> > In a test I'd like to use wait_for_log() to find a bunch of log messages
> > emitted in sequence. A reasonable looking pattern for that would be:
> >
> >     $log_location = -s $node->logfile;
> >
> >          $log_location = $node->wait_for_log(qr/first-message/, $log_location);
> >          $log_location = $node->wait_for_log(qr/second-message/, $log_location);
> >
> > Except that that doesn't work, because what wait_for_log returns is:
> >
> >         my $log =
> >           PostgreSQL::Test::Utils::slurp_file($self->logfile, $offset);
> >
> >         return $offset + length($log) if ($log =~ m/$regexp/);
> >
> > Which, afaict, boils down to the current end of the logfile.
> >
> > Could we instead determine where in the string our regex matched, and return
> >     $offset + $that_magic_number
> >
> > Assuming that could be made work, does anybody see a reason not to do that?
>
> In principle it seems quite reasonable, but I haven't looked at all the
> current uses to see if they will be upset.

All tests pass [1] after changing it ($+[0] seems to be the thing to use).

But of course it's possible that changing the semantics like that makes some
test less aggressive, finding an earlier occurrence of the searched-for string
than desired. I've a bit of a hard time imagining a non-contrived example,
but...

I did skim through all the users that use the return value in pg and based on
a quick look they all seem ok.

Greetings,

Andres Freund

[1] https://cirrus-ci.com/build/6002889136537600