Re: Why does wait_for_log() return current file size
От | Andres Freund |
---|---|
Тема | Re: Why does wait_for_log() return current file size |
Дата | |
Msg-id | bylmkzu2lqpdjfwcefvtypfukc2tloginjm7dw3zyn7rkpqbbj@chxpnjpc737v обсуждение исходный текст |
Ответ на | Re: Why does wait_for_log() return current file size (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: