Re: Implement generalized sub routine find_in_log for tap test

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Implement generalized sub routine find_in_log for tap test
Date: 2023-05-25 22:39:17
Message-ID: ZG/jlbT0eIME+MFW@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2023-05-25 22:40:16 Re: Avoiding another needless ERROR during nbtree page deletion
Previous Message Tom Lane 2023-05-25 22:06:47 Re: ERROR: no relation entry for relid 6