Re: Implement generalized sub routine find_in_log for tap test

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Implement generalized sub routine find_in_log for tap test
Дата
Msg-id ZG/jlbT0eIME+MFW@paquier.xyz
обсуждение исходный текст
Ответ на Re: Implement generalized sub routine find_in_log for tap test  (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>)
Ответы Re: Implement generalized sub routine find_in_log for tap test  (vignesh C <vignesh21@gmail.com>)
Список pgsql-hackers
On Thu, May 25, 2023 at 06:34:20PM +0100, Dagfinn Ilmari Mannsåker wrote:
> However, none of the other functions in ::Utils know anything about node
> objects, which makes me think it should be a method on the node itself
> (i.e. in PostgreSQL::Test::Cluster) instead.  Also, I think log_contains
> would be a better name, since it just returns a boolean.  The name
> find_in_log makes me think it would return the log lines matching the
> pattern, or the position of the match in the file.
>
> In that case, the slurp_file() call would have to be fully qualified,
> since ::Cluster uses an empty import list to avoid polluting the method
> namespace with imported functions.

Hmm.  connect_ok() and connect_fails() in Cluster.pm have a similar
log comparison logic, feeding from the offset of a log file.  Couldn't
you use the same code across the board for everything?  Note that this
stuff is parameterized so as it is possible to check if patterns match
or do not match, for multiple patterns.  It seems to me that we could
use the new log finding routine there as well, so how about extending
it a bit more?  You would need, at least:
- One parameter for log entries matching.
- One parameter for log entries not matching.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: no relation entry for relid 6
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Avoiding another needless ERROR during nbtree page deletion