Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 26 May 2023 07:39:17 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Dagfinn Ilmari =?iso-8859-1?Q?Manns=E5ker?= <ilmari@ilmari.org>
Cc: vignesh C <vignesh21@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Implement generalized sub routine find_in_log for tap test
Message-ID: <ZG/jlbT0eIME+MFW@paquier.xyz>
References: <CALDaNm0YSiLpjCmajwLfidQrFOrLNKPQir7s__PeVvh9U3uoTQ@mail.gmail.com>
 <87cz2otiw3.fsf@wibble.ilmari.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="6uuq3SPL+598jBM5"
Content-Disposition: inline
In-Reply-To: <87cz2otiw3.fsf@wibble.ilmari.org>
Archived-At: <https://www.postgresql.org/message-id/ZG/jlbT0eIME%2BMFW%40paquier.xyz>
Precedence: bulk


--6uuq3SPL+598jBM5
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 25, 2023 at 06:34:20PM +0100, Dagfinn Ilmari Manns=E5ker 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.
>=20
> 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

--6uuq3SPL+598jBM5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmRv45UACgkQnvQgOdby
QH0giA//YG/yd/J3jPM7gSbisUJMbrwd64hOXcjsgP6bMqFM216ugVTb0iLYELUM
MzHshHOQ1+basS/Q7Y2XFxqJi/WRlRE65c3MqoG08b5K0OeElJypjvK+jIbEkhDK
jcuPmDotc9HyVTu8jaKNyveTETy+nTIBZ158HXnR3rbYkzoVp45isvff14zLawn5
GwUYDlaYym8p/RUZCN1HzR59LMeuF5FqqC7vJ1lo4+JPsy4nE6awkqjsA2aluyDl
yiNlcgbTkGCxVlcIrw/F0vrGJ9jZRMIQw6/vWyJiRtVx8INGh0W+08TfGUJVs9ro
Qub5554V7ppY2RdBePMMD5NHvxeku9/zRT1S1x+it+ie6YvDxVMZs1f+7S5jkCDN
42w1vJbp4CyyyY1wwttWaHRaaoLWsMkQXdgIAksFKhEuRZYYou65F8fwjauCrIyT
/2YTTDky57+OczMyNqqq6CWALfKFZ7JLXMEIoN0egBMfLtw3wm1paZAXrI/iLXaU
hUht1cg7fwg6Sa1iZihkIOKuqGgNtw2ixe3VHPEObB+heZ70EVVLBnTyAKknjCpp
ZHM3oMueyDbPQ9x9YlAV64PAW+a+YlfyBEeYOgDQP+MCIU7X9uLio0sPJf/Uq17d
JB5NNEOAJgdT2OEm0V0pKXw+ik0GvvLyyxxj1yTGQzE2YeAvbao=
=mNZv
-----END PGP SIGNATURE-----

--6uuq3SPL+598jBM5--