Re: Implement generalized sub routine find_in_log for tap test

From: vignesh C <vignesh21(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Implement generalized sub routine find_in_log for tap test
Date: 2023-06-05 16:09:22
Message-ID: CALDaNm2Q_uE0Ash_1LTbqDQGSEM-8e9wjtuJ0QKTVdKNG34JWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 4 Jun 2023 at 03:51, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, May 29, 2023 at 07:49:52AM +0530, vignesh C wrote:
> > Thanks for the comment, the attached v3 version patch has the changes
> > for the same.
>
> -if (find_in_log(
> - $node, $log_offset,
> - qr/peer authentication is not supported on this platform/))
> +if ($node->log_contains(
> + qr/peer authentication is not supported on this platform/),
> + $log_offset,)
>
> This looks like a typo to me, the log offset is eaten.
>
> Except of that, I am on board with log_contains().

Thanks for fixing this.

> There are two things that bugged me with the refactoring related to
> connect_ok and connect_fails:
> - check_connect_log_contents() is a name too complicated. While
> looking at that I have settled to a simpler log_check(), as we could
> perfectly use that for something else than connections as long as we
> want to check multiple patterns at once.
> - The refactoring of the documentation for the routines of Cluster.pm
> became incorrect. For example, the patch does not list anymore
> log_like and log_unlike for connect_ok.

This new name suggested by you looks simpler, your documentation of
having it in connect_ok and connect_fails and referring it to
log_check makes it more clearer.

Regards,
Vignesh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Morris de Oryx 2023-06-05 16:20:34 Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function
Previous Message Morris de Oryx 2023-06-05 16:03:46 Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function