Re: Implement generalized sub routine find_in_log for tap test - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Implement generalized sub routine find_in_log for tap test
Date
Msg-id ZG/jlbT0eIME+MFW@paquier.xyz
Whole thread Raw
In response to Re: Implement generalized sub routine find_in_log for tap test  (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>)
Responses Re: Implement generalized sub routine find_in_log for tap test
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ERROR: no relation entry for relid 6
Next
From: Peter Geoghegan
Date:
Subject: Re: Avoiding another needless ERROR during nbtree page deletion