Re: Implement generalized sub routine find_in_log for tap test
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Cc: vignesh C <vignesh21@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-05-25T22:39:17Z
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
Commits
-
Refactor routine to find single log content pattern in TAP tests
- ced4cc30d5de 11.21 landed
- 3509a060d731 12.16 landed
- a9231fedae7a 13.12 landed
- 28af91b4e797 14.9 landed
- e25e5f7fc6b7 15.4 landed
- 392ea0c78fdb 16.0 landed
-
Refactor log check logic for connect_ok/fails in PostgreSQL::Test::Cluster
- 30469a6ed424 14.9 landed
- 7fa7911c7675 15.4 landed
- 26eaf82e7138 16.0 landed